Linux 系统的组成部分 Linux 系统主要由内核、根文件系统组成。 # 内核的功能 进程管理、内存管理、网络协议栈、文件系统、驱动程序、安全功能 运行中的系统环境可分为两层 用户空间：应用程序（进程或线程） 内核空间：内核代码（系统调用） 内核设计流派 单内核设计：把所有功能集成于同一个程序。Linux 微内核设计：每种功能使用一个单独的子系统实现。Windows、Solaris 内核的组成部分 核心文件：/boot/vmlinuz-3.10.0-957.21.3.el7.x86_64 ramdisk：临时根文件系统。/boot/initramfs-3.10.0-957.21.3.el7.x86_64.img 模块文件：/lib/modules/3.10.0-957.21.3.el7.x86_64/* .* Filesystem Hierarchy Standard 文件系统层级结构标准 所有 Linux 发行版遵循的根文件系统结构的标准规范，明确规范了根下所有目录的命名规范与职能。 系统分区规划的意义 BIOS Boot (标准分区)：Boot Loa....
分布式事务 单体应用被拆为分布式应用，一个借口需要调用多个服务，且操作不同的数据库，数据一致性难以保障。 常见解决方案 2PC : 两阶段提交， 基于 XA 协议 TCC : Try、Confirm、Cancel 框架 GTS -> 开源 Fescar 链接 LCN 链接 RocketMQ4.X 分布式事务消息架构 RocketMQ 事务消息 RocketMQ 提供分布事务功能，通过 RocketMQ 事务消息能达到分布式事务的最终一致。 半消息 Half Message 暂不能投递的消息(暂不能消费)，Producer 已经将消息成功发送到了 Broker 端，但是Broker 端未收到 Produce 对该消息的二次确认，此时该消息被标记成“暂不能投递”状态，处于该种状态下的消息即半消息。 消息回查 由于网络闪断、生产者应用重启等原因，导致某条事务消息的二次确认丢失，消息队列 RocketMQ 服务端通过扫描发现某条消息长期处于“半消息”时，需要主动向消息生产者询问该消息的最终状态（Commit 或是 Rollback），该过程即消息回查。 整体交互流程 ....
消息偏移量 Offset 一个 Topic 下面有多个 message queue，message queue 是无限长的数组，一条消息进来下标就会涨 1，下标就是 offset（索引的位置），消息在某个 MessageQueue 里的位置，通过 offset 的值可以定位到这条消息，或者指示 Consumer 从这条消息开始向后处理。 message queue 中的 maxOffset 表示消息的最大 offset, maxOffset 并不是最新的那条消息的 offset，而是最新消息的 offset+1，minOffset 则是现存在的最小 offset。 fileReserveTime=48 默认消息存储 48 小时后，消息会被物理地从磁盘删除，message queue 的 min offset 也就对应增长。（1-5000，消息删除之后，1001-5000）所以比 minOffset 还要小的那些消息已经不在 broker 上了，就无法被消费。 Offset 的存储类型 本地文件类型：DefaultMQPushConsumer 的 BROADCASTING 模式，各....
常见核心配置 consumeFromWhere 配置 参考 CONSUME_FROM_FIRST_OFFSET： 初次从消息队列头部开始消费，即历史消息（还储存在broker的）全部消费一遍，后续再启动接着上次消费的进度开始消费 CONSUME_FROM_LAST_OFFSET： 默认策略，初次从该队列最尾开始消费，即跳过历史消息，后续再启动接着上次消费的进度开始消费 CONSUME_FROM_TIMESTAMP : 从某个时间点开始消费，默认是半个小时以前，后续再启动接着上次消费的进度开始消费 allocateMessageQueueStrategy:负载均衡策略算法，即消费者分配到 queue 的算法，默认值是 AllocateMessageQueueAveragely 即取模平均分配。 offsetStore：消息消费进度存储器 offsetStore 有两个策略： * LocalFileOffsetStore ： Consumer记录消息的消费进度。 * RemoteBrokerOffsetStor ： Broker记录消息的消费进度。 广播模式默认使用Lo....
简介 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宕机，磁盘损坏情况，会丢失少量消息 双主双从，多主多从模式（同步双写） 优点：同步双写方式，主备都写成功，向应用才返回成功，服务可用性与数据可用性都非常高 缺点：性能比异步复制模式略低，主宕机后，....
