消息中心设计

设计一个消息中心，需要满足高可用、可管理、满足业务线的隔离性、高吞吐以及高可靠。思路演变如下。

根据需求可靠性，初步定ActiveMQ，满足可靠性。其优势如下：

系统解耦，流量销峰，提高服务响应速度，提升系统伸缩性，提高系统可用性。

但只是简单的消息生产、发送、消费，流程如下。

缺点如下：

1、可靠性：分布式事务成本高；Topic容易丢消息；开机、listener注册过程的问题；关机时内存中的topic消息必须消费完成；DB异常或硬件故障。

2、性能和吞吐量：单producer，单机吞吐量不高(数万tps)，大消息量性能下降。

3、拓展性：理想的是通过简单的增加机器数量即可提升整个系统的吞吐量，ActiveMQ无法做到，另在设计的局限上Topic类型的消息只能单线程消费。

4、高可用成本高：集群故障转移能力弱，一旦AMQ出现问题，只能通过域名切换的方式；集群方案都不尽理想。

AMQ的部署方式：
1、主备模式：master-slave，缺点无法做到load balance，备模式只有在主节点不可用时，slave才会被启用；
AMQ通过抢主的方式来决定谁是master，但DB害死单点，高版本AMQ可以引入zk，数据库做replicate解决单点问题，但增加了运维复杂度；
2、broker-Cluster：AMQ通过broker桥接的方式组成集群，消息可以发送至任意实例，但这种方式运维相对复杂，在一台AMQ宕机的情况下也可能出现丢消息的情况。
3、双主(当前采用的)：可load balance，也解决了DB单点问题。

kafka优势：kafka集群吞吐量非常大且容易水平拓展。
多机房部署，每个机房两大kafka集群，集群间使用SmartCluster来做切换。
kafka自身把不同的topic分为不同的partition，partition之间有不错的隔离性。
消费端采用了对于不同的消费者以不同的consumer group，消息推送端使用单独的线程池进行隔离；

集中消费端KMQ的高可用、水平拓展
1、启动多台KMQ，KMQ数量可以动态水平拓展，多台KMQ在Zookeeper上抢主；
2、抢到主的KMQ实例负责调度消费者实例在那台KMQ实例上启动；
3、调度算法保证整个集群对于同意消费者至少有三个消费者实例。

统一消息发送端
简化了消息的发送，统一消息发送，规范了消息落地、跟踪监控埋点。
1、灵活切换消息发送通道。
2、延迟消息支持，客户端落地、延迟发送，性能较集中式的延迟消息要好。
3、同一应用不同Topic之间发送队列和发送线程池隔离
4、通过配置热更新功能，动态调整发送集群。
5、客户端消息发送的重试，使用隔离的重试队列。保证消息可靠送达。

可靠性保证
1、消息落地(每月分区，做分区表)与业务事务绑定，业务表的落地与消息表的落地在同一事务中，保证数据的一致性；
2、Post commit机制，在业务事务提交之后消息才会发送出来，解决异常发送的问题。
    比如业务端在处理事务时，消息已经发出并被生产者消费，导致数据不一致；
    另解决了消息发送慢导致DB连接占用过长的问题
3、重试机制+监控报警，确保可靠送达

最终的架构图