同步架构与异步架构
背景
把智能系统比喻成KFC营业厅，处理器是窗口和窗口后面的服务员（把一个窗口当作一个核心），指令集是后面排队的人，窗口是数据吞吐量。 当中午就餐人多的时候，一个窗口肯定忙不过来， 这时候就需要增加窗口
解决方案
1.在窗口后面增加多个服务员，分担一下工作
2.新增多个窗口
分析
方案一就是异步架构，方案二同步架构
一个窗口是不可能比上多个窗口的工作效率
对比结论
优点：异步架构设计简单，实现方便。
缺点：性能低，吞吐量差。
总结：如果对处理并发量不高的系统。优先选择异步架构！！！
异步能够给架构带来什么
优化前端，主动把控与用户的会话，让用户体验更好。
高并发处理，能够比较简单实现负载均，案例：12306
提供架构容错能力。高可用
系统代码更加安全，不用使用多线程，所以也会碰到线程死锁等问题，对信息同步也更加方便。
异步--高并发场景
异步编程—给我们带来什么
async/await
非阻塞I/O可以使CPU与I/O并不依赖，可以更大程度的利用资源
对于网络应用，并行带来的优势更大，利于分布式和云的应用
异步，自动多线程，主动处理软件架构问题，如：高并发，高可用。
异步—高可用场景
高可用实现
反向代理/负载均衡，实现网站的高可用
Processor，通过重复Worker实现高可用的架构
微服务-高并发/高可用实现
前端MQ订阅，后端Processer调用微服务实现
高并发，利用网关，很方便的进行服务分流，eg：Docker
高可用，MQ防止数据丢失，结合线程池/反向代理网关[k8s]插件,实现微服务的高可用
缓存—给我们带来什么
提高数据使用性能和安全…..
高可用，实现内存数据的高可用，结合nginx等，可以很方便的实现软件高可用
高并发，Redis数据多节点异地存储，可以实现多节点分流
微服务-高并发/高可用场景
前端MQ订阅，后端Processer调用微服务实现
高并发，利用网关，很方便的进行服务分流，eg：Docker
高可用，MQ防止数据丢失，结合线程池/反向代理网关[k8s]插件,实现微服务的高可用
MQ--高可用/高并发
高可用
高可用，服务的持续响应
解耦，MQ的消息生产者和消费者互相不关心对方是否存在
并发，MQ有生产者集群和消费者集群，所以客户端是亿级用户时，他们都是并行的。从而大大提升响应速度。
削峰，因为MQ能存储的消息量很大，所以他可以把大量的消息请求先存下了，然后再并发的方式慢慢处理。
CQRS（读写分离）—高并发场景
1. 分工明确，可以负责不同的部分
2. 将业务上的命令和查询的职责分离能够提高系统的性能、可扩展性和安全性。并且在系统的演化中能够保持高度的灵活性，能够防止出现CRUD模式中，对查询或者修改中的某一方进行改动，导致另一方出现问题的情况。
3. 逻辑清晰，能够看到系统中的那些行为或者操作导致了系统的状态变化。
4. 可以从数据驱动(Data-Driven) 转到任务驱动(Task-Driven)以及事件驱动(Event-Driven) 】
Kafka—阿里云PAAS产品
消息队列Kafka版是阿里云提供的分布式、高吞吐、可扩展的消息队列服务。消息队列Kafka版广泛用于日志收集、监控数据聚合、流式数据处理、在线和离线分析等大数据领域，已成为大数据生态中不可或缺的部分。 https://help.aliyun.com/document_detail/68151.html?spm=5176.167616.1288903.btn3.537a5a1cQ3KmhQ
高容量存储：能在商业硬件上存储高容量的数据，实现可横向扩展的分布式系统。
一对多消费模型：“发布/订阅”模型，支持同份数据集能同时被消费多次。
同时支持实时和批处理：支持本地数据持久化和Page Cache，在无性能损耗的情况下能同时传送消息到实时和批处理的消费者
数据库—高可用/并发
数据库：数据持续化，把内存数据保存为文件【系列化持久化】 保存数据，保障数据安全，传输
高并发给它带来那些调整：资源【磁盘/cpu/内存】，I/O Buffer 解决方案：读写分离【发布订阅】分库分表【入门级】，
高可用给它带来什么问题：数据库宕机危机 解决方案：主从热备，定时BackUp【入门们】 周全量备份，周一对数据库做一个全面备份，存储到其他OSS 日增量备份，每天相对于前天，对比数据做一个增量备份。存储到其他OSS
异步架构常见的坑
1.复杂度变高，程序之间来回回调，工程师刚入手时，调试或解决问题很不方便 比较合适的方法，多用中间件，Redis/MQ/Kafla/DB，少用多线程/程序回调
2.时间成本 对实时性比较强的程序，有很大时间消耗。不建议使用异步编程
3.比较推荐：缺点，异步的代码同步化，可能会导致性能上的问题(降低性能)
