标签：路由 消息发送 简单 bsp 内存映射 需求 通知 ash 解耦
最近正在研究rocketmq，简单记录下设计的不同
互联网系统中Rpc、服务治理、消息中间件基本都是标配，消息中间件能解耦，削峰，高可用并能间接提供达到最终一致性
消息中间件中，消息消费分为最多一次，至少一次和刚好一次，如果需要实现刚好一次，则系统设计难度增大，系统性能损失增加，权衡利弊，rocket实现的是最少一次，消费端可能会重复接收消息（ACK模式下，ACK消息可能丢失），由消费端幂等消费
为什么不用zk，还是从实际需求出发，Topic路由信息无需在集群之间保持强一致性，最终一致即可，从而减少对zk的依赖和性能的损失
消息存储方面，rocket引入文件组，无限循环使用，commitlog文件每个1G，顺序写，引入内存映射，相同主题的消息被顺序存储在同一文件中，还提供定时清理等防止过度堆积，消费队列文件和索引文件提升读性能，
消息过滤，基于tag等，在存储设计上基于hash等方式提升过滤效率，可以从Broker或者消费端过滤，broker端过滤可以减少传递到消费端的消息，减少网络损失，消费端过滤可以由消费者任意定义
定时消息，如果要支持任意精度的定时消息消费，必须在消息服务端对消息进行排序，势必带来很大的性能损耗，rocketmq设计不支持任意进度的定时消息，只支持特定延迟级别
客户端支持Push、pull两种模式
线程池设计，rocketmq会根据不同的任务类型创建不同的线程池，如果该类型没注册，则由other之类的线程池统一处理
Namesrv之间数据可以不一致，彼此之间互不通信
消息发送端提供容错机制，这个地方之前我就有疑问，为什么在客户端或者消费端获取消息存储meta信息之后，namesrv发现变化后不会通知他们。。。原来是由meta使用端的容错机制来保证高可用，降低namesrv的复杂性
标签：路由 消息发送 简单 bsp 内存映射 需求 通知 ash 解耦
原文地址：https://www.cnblogs.com/it-worker365/p/10130570.html
