消息队列的前世今生
1.系统崩溃
解决方案：解耦。将点击行为记录到消息队列中，从而当存储服务崩溃时，还能够保留行为记录。
2.服务器处理能力有限
解决方案：削峰。将订单放在消息队列汇总，每次只取10个请求进行处理。
3.链路耗时长尾
解决方案：异步。将点击行为记录到消息队列中，然后异步完成剩下的操作步骤。
4.日志如何处理
消息队列（MQ），是保存消息的一个容器，本质是队列。但这个队列需要高吞吐，高并发，并且高可用。
历史：
TIB->IBM MQ/WebSphere->MSMQ->JMS->AMQP/RabbitMQ->Kafka->RocketMQ->Pulsar
Kafka:分布式、分区的、多副本的日志提交服务，在高吞吐场景下发挥较为出色。
RocketMQ:低延迟、强一致、高性能、高可靠、万亿级容量和灵活的可扩展性，在一些实时场景中运用较广。
Pulsar:是下一代云原生分布式消息流平台、集消息、存储、轻量级函数式计算为一体、采用存算分离的架构设计。
BMQ:和Pulsar架构雷狮，存算分离，初期定位是承接高吞吐的离线业务场景，逐步替换掉对应的Kafka集群。
