- 分布式系统之间的交互主要有两种形式：RPC和消息队列
选择用那种方式进行交互主要参考它们之间的关系是否强依赖，比如在一个简单的下单的业务流程中需要减库存、扣钱、记录日志、发短信。其中减库存和扣钱肯定是要需要RPC调用的，日志记录和发短信可以用消息的形式交互。
- 在大型互联网中，主要采用消息中间件来进行业务的解耦和操作的异步化。
- 功能需求:实时消息，定时消息，事务消息，保证顺序
- 性能，平均要去2md
- 可用性，一般会要求99.99%的可用性，即365天不可用的时间不能超过1小时。
- 可靠性，要去消息不会丢失。
- kafka
- 首先要看外部依赖的可用性，如果某个系统强依赖了外部的其他服务，那么该系统的可用性必然和外部服务的可用性相关。(强依赖外部服务不可用了本服务也就不可用了)
- 从架构图可以看出Kafka只是依赖了zookeeper，而zookeeper本身是高可用的(2N+1个节点的ZK集群可以容忍N个节点故障)，所以不会对整个集群的可用性造成影响。
- 谈高可用性必然会涉及到备份的问题，没有备份就意味着存在单点问题，也没有高可用性可言了。
- 可靠性。一般通过两点来保证: a. 成功写入后做持久化
b. 备份到其他物理节点
只要满足以上两点就可以保证除所有节点都发生永久性故障的情况下数据不会丢失。 kafka broker上写入的数据都会刷盘(可以是异步也可以是同步)，也会备份到其他物理节点，所以以上两点都满足。 消息丢失包括没有被中间件接收，从磁盘上被消耗，cunsumer没有办法消费(比如confumer收到消息后进行ack之后再消费，如果在消息之前Crash了，那么下一次也不会拿到这条消息这种场景也属于消息丢失)- 优点:
a. 部分功能托管给了zk，自身只需要关注消息相关的内容。
b. 机器利用率高。从备份的策略可以看出不同broker之间数据是互为备份的，这样的结构相对于主从模式提高了机器的利用率(大部分主从模式，从都是无用的状态)
缺点: 引入了zk，增加了外部依赖，增加了运维的复杂度
