简介 Docker引擎是用来运行和管理容器的核心软件。基于开放容器计划(OCI)相关标准要求，Docker引擎采用了模块化的设计原则，其组件是可替换的。 Docker引擎主要组件构如下： Docker客户端 Docker守护进程 containerd runc 摆脱LXC LXC提供了对诸如：命名空间、控制组、等基础工具的操作能，他们是基于Linux内核的容器虚拟化技术。 因为LXC是基于Linux，这不利于Docker实现跨平台，其次，如果核心的组件依赖于外部工具，会给Docker项目带来巨大的风险。因此，Docker公司开发了名为Libcontainer的自研工具，用于替代LXC。Libcontainer的目标是成为与平台无关的工具，可基于不同内核为Docker上层提供必要的容器交互功能。在Docker 0.9版本中，Libcontainer取代 拆分大而全的Docker daemon 随着时间的退役，Docker daemon的整体性带来了越来越多的问题。 难于变更。 运行越来越慢。 Docker公司意识到这些问题，开始努力着手拆解大而全的Docker da....
常见核心配置 VIM /test/rocketmq/distribution/target/apache-rocketmq/conf/2m-2s-sync/broker-a.properties compressMsgBodyOverHowmuch ：消息超过默认字节 4096 后进行压缩 retryTimesWhenSendFailed : 失败重发次数 maxMessageSize : 最大消息配置，默认 128k topicQueueNums : 主题下面的队列数量，默认是 4 autoCreateTopicEnable : 是否自动创建主题 Topic, 开发建议为 true，生产要为 false defaultTopicQueueNums : 自动创建服务器不存在的 topic，默认创建的队列数 autoCreateSubscriptionGroup: 是否允许 Broker 自动创建订阅组，建议线下开发开启，线上关闭 brokerClusterName : 集群名称 brokerId : 0 表示 Master 主节点 大于 0 表示从节点 brokerIP1 : Br....
常见集群模式 推荐方案 2、4、5 单节点 优点：本地开发测试，配置简单，如果采用同步刷盘，消息一条都不会丢。 缺点：不可靠，如果宕机，会导致服务不可用 主从(异步、同步双写) 优点：同步双写消息不丢失, 异步复制存在少量丢失 ，主节点宕机，从节点可以对外提供消息的消费，但是不支持写入。 缺点：主备有短暂消息延迟，毫秒级，目前不支持自动切换，需要脚本或者其他程序进行检测然后进行停止broker,重启让从节点成为主节点 双主 优点：配置简单, 可以靠配置RAID磁盘阵列保证消息可靠，异步刷盘丢失少量消息 缺点: master机器宕机期间，未被消费的消息在机器恢复之前不可消费，实时性会受到影响 双主双从，多主多从模式（异步复制） 优点：磁盘损坏，消息丢失的非常少，消息实时性不会受影响，Master 宕机后，消费者仍然可以从Slave消费 缺点：主备有短暂消息延迟，毫秒级，如果Master宕机，磁盘损坏情况，会丢失少量消息 双主双从，多主多从模式（同步双写） 优点：同步双写方式，主备都写成功，向应用才返回成功，服务可用性与数据可用性都非常高 缺点：性能比异步复制模式略低，主宕机后，....
Trouble Shooting 多网卡下为 rocketmq 指定 IP # 修改配置文件 vim /test/rocketmq/distribution/target/apache-rocketmq/conf/broker.conf brokerIP1=192.168.31.220 #新增内容 # 启动Broker命令命令 nohup sh /test/rocketmq/distribution/target/apache-rocketmq/bin/mqbroker -n 192.168.31.220:9876 -c /test/rocketmq/distribution/target/apache-rocketmq/conf/broker.conf & 控制台查看不了数据，提示连接 10909 错误 原因：Rocket默认开启了VIP通道，VIP通道端口为10911-2=10909 解决：阿里云安全组需要增加一个端口 10909 消息发送 添加 Maven 相关依赖 <dependency> <groupId>org.apache.rocket....
RocketMQ4.x 特性 支持 Broker(减少带宽的传输)和 Consumer 端消息过滤 支持发布订阅模型，和点对点， 支持拉 pull 和推 push 两种消息模式 单一队列百万消息、亿级消息堆积 支持单 master 节点，多 master 节点，多 master 多 slave 节点 任意一点都是高可用，水平拓展，Producer、Consumer、队列都可以分布式 消息失败重试机制、支持特定 level 的定时消息 新版本底层采用 Netty 4.3.x 支持分布式事务 适合金融类业务，高可用性跟踪和审计功能。 角色 Producer:消息生产者 Producer Group:消息生产者组，发送同类消息的一个消息生产组 Consumer:消费者 Consumer Group:消费同类消息的多个实例 Tag:标签，子主题（二级分类）对 topic 的进一步细化，用于区分同一个主题下的不同业务的消息 Topic:主题， 如订单类消息，queue 是消息的物理管理单位，而 topic 是逻辑管理单位。一个 topic 下可以有多个 queue。（默认自动创建是 4 个....
JMS 消息服务 Java 消息服务（Java Message Service),Java 平台中关于面向消息中间件的接口。JMS 是一种与厂商无关的 API，用来访问消息收发系统消息，它类似于 JDBC(Java Database Connectivity)。—— JDBC 是可以用来访问许多不同关系数据库的 API。而 JMS 则提供同样与厂商无关的访问方法，以访问消息收发服务。许多厂商都支持 JMS。 消息中间件使用场景 解耦：订单系统-》物流系统（责任转移） 异步：用户注册-》发送邮件（串行变并行，加快响应速度） 削峰：秒杀、日志处理（缓冲队列） 消息中间件常见概念 JMS 提供者：连接面向消息中间件的，JMS 接口的一个实现，RocketMQ,ActiveMQ,Kafka 等等 JMS 生产者(Message Producer)：生产消息的服务 JMS 消费者(Message Consumer)：消费消息的服务 JMS 消息：数据对象（POJO） JMS 队列：存储待消费消息的区域 JMS 主题：一种支持发送消息给多个订阅者的机制 JMS 消息通常有两种类型：点对点（....
Jconsole JConsole (Java Monitoring and Management Console）是一种基于 JMX 的可视化监视、管理工具，它管理部分的功能是针对 JMXMBean 进行管理，由于 MBean 可以使用代码、中间件服务器的管理控制台或者所有符合 JMX 规范的软件进行访问。 jconsole集成了线程与内存的可视化展示。 Jconsole连接方式 本地连接：通过JDK/bin目录下的“jconsole.exe”启动JConsole 后，将自动搜索出本机运行的所有虚拟机进程，不需要用户自己再使用 jps 来查询了。 远程连接 # 生成项目jar mvn install # scp将jar包进行远程复制 sudo scp /Users/daniel/Desktop/jvm-demo-0.0.1-SNAPSHOT.jar root@172.16.244.151:/usr/local # 将jar包启动 #nohup代表以守护线程的方式启动 # -Dcom.sun.management.jmxremote.port 开启远程访问JXM端口 nohup....
