这是我参与[第五届青训营]伴学笔记创作活动的第13天
日志处理
Log ——> 信息队列 ——> logstash ——> ES ——> kibana
信息队列（MQ）保存信息的一个容器，本质是个队列。但这个队列，需要支持高吞吐，高并发，并且高可用。
graph TD
TIB --> IBM-MQ/WebSphere --> MSMQ -->JMS --> AMQP/RabbitMQ -->Kafka --> RocketMQ --> Pulsar
- TIB：诞生于1985年，服务于金融机构和新闻机构
- IBM-MQ/WebSphere：诞生于1998年，商业信息队列平台市场主要玩家
- MSMQ：微软发布于1997年
- JMS：诞生于2001年本质上是一套javaAPI
- AMQP（统一）/RabbitMQ：规范发布于2004年，同年RabbitMQ面市
- Kafka：2010年由Linked开源
- RocketMQ：2011年阿里中间件团队自研
- Pulsar：2012年诞生于Yahoo内部
常见的
- kafaka：分布式、分区的、多副本的日志提交服务，在高吞吐场景下发挥较为出色（广 ）
- RocketTMQ：低延迟、强一致、高性能、高可靠、万亿级容量和灵活的可扩展性，在一些实施场景中运用较广（阿里自研）
- Pulsar：是下一代云原生分布式信息流平台，集信息、存储、轻量化函数式计算为一体、采用存算分离的架构设计（腾讯）
- BMQ：和Pulsar架构类似，存算分离，出其定位是承接高吞吐的利息按业务场景，逐步替换掉对应的Kafka集群（字节）
1.异步处理：
场景说明：用户注册后，需要发注册邮件和注册短信。传统的做法有两种 1.串行的方式；2.并行方式
串行方式：将注册信息写入数据库成功后，发送注册邮件，再发送注册短信。以上三个任务全部完成后，返回给客户端。
并行方式：将注册信息写入数据库成功后，发送注册邮件的同时，发送注册短信。以上三个任务完成后，返回给客户端。与串行的差别是，并行的方式可以提高处理的时间2.应用解偶：
场景说明：用户下单后，订单系统需要通知库存系统。传统的做法是，订单系统调用库存系统的接口。、 传统模式的缺点：假如库存系统无法访问，则订单减库存将失败，从而导致订单失败，订单系统与库存系统耦合
解决方法：引入消息队列
订单系统：用户下单后，订单系统完成持久化处理，将消息写入消息队列，返回用户订单下单成功
库存系统：订阅下单的消息，采用拉/推的方式，获取下单信息，库存系统根据下单信息，进行库存操作
假如：在下单时库存系统不能正常使用。也不影响正常下单，因为下单后，订单系统写入消息队列就不再关心其他的后续操作了。实现订单系统与库存系统的应用解耦
