架构是啥，好吃吗？
写在前面的话：时间：2021.12.23 地点：陕西西安（居家办公） 人物：冷妆,刚入行的java小菜鸡事件起因:在哪吒社区得到《亿级流量java高并发与网络编程实战》 事件经过:西安因为疫情居家办公，而我的电脑落在办公区域,大型社4现场 |
续前文：高并发之概述
系统分析原则
在开发大型系统时，除了根据业务需求实现相应的模块外，大型系统在设计时需要重点考虑的一些原则和设计要点来切实的掌控系统开发的思考
由高并发原则（高并发使用不当）->容错原则->(实现高并发解决方案)CAP原则->幂等性原则->可扩展原则->可维护性原则->可监控原则
高并发原则
为了保证项目在高并发环境下的正常运行，可以通过垂直扩展和水平扩展来实现
垂直扩展:通过软件技术或者升级硬件来提高单机的效率(呐呢，愚公移山吗?)
水平扩展:通过增加服务器的节点个数来横向扩展系统的性能（有点集群的意思）
最终的结果很明显:分布式架构现成为了主流，高并发的最终解决方案认可了水平扩展
即使单机的性能是有限的，但不可否认的是垂直扩展更方便，更快，所以就可以根据实际项目酌情
考虑
容错原则
未雨绸缪始终是正确的决定，高并发使用不当，防患于未然，系统具有一定的容错性是必然的
通用场景用例子来说明：
SpringBoot+Redis实现分布式缓存，使用MQ实现分布式场景下的事务一致性
使用MQ，PRG模式，Token令牌机制，数据库唯一约束等解决重复提交问题
使用"去重表"实现操作的幂等性
使用集群或者zookeeper解决失败迁移的问题
分布式系统中，网络延迟问题不可避免,那该采取什么策略来解决呢
通过session有效时长进行判断(面试好像有遇到过这个问题)
心跳检测机制判断(感觉有点像JVM中判断垃圾的可达化分析)：客户每隔60s向服务器发送一次心跳，如果服务器能够接收到就说明客户端的状态是正常的；如果服务器没有收到，就再等待客户端的下一次60s发来的心跳,如果连续N次都没接收到某个客户的心跳，就可以认定此客户端已经断线
预先隔离手段
像秒杀可预知时间的流量暴增情况，提前将秒杀服务器隔离成单独的服务(对于这个隔离，笔者有心理恐惧，街上的救护车一直在响)，流量不大可以使用多级缓存来解决
这里去查了一下PRG模式，Post/Redirect/Get 防止重复提交
CAP原则（这个还是比较熟悉的）
分布式系统中，多个节点数据同步以及该如何考虑呢？
C：Consistency一致性--》在同一时刻，所以节点的数据是相同的
A：Availability可用性--》在合理的时间范围内，系统能提供正常的服务
P：Partition tolerance分区容错性--》当分布式系统中部分节点故障时，系统能正常运行
CAP原则：在任何一个分布式系统中，CAP三者不可兼得，最多同时满足两个。因为网络问题，所以以P为基础选择，然后对C,A根据实际业务来选择
幂等性原则
提及幂等原则，自然离不开的就是分布式系统网络所带的问题
幂等性原则是对调用服务器次数的一种限制，无论某个服务器提供的接口调用一次或多次结果是一样的
对于分布式系统来说，幂等性的实现
1.可以在写操作之前通过执行读操作来实现
支付例子来说明的话：读取当前的状态来进行判断（已支付或者未支付），然后做出写的操作（支付成功或者支付失败继续支付）
2.”去重表“的方式来实现
通过第一次操作之前生成全局唯一ID-》去重表中查找判断是否存在-》存在，返回结果，不存在，存入去重表
3.CAS算法
Compare And Swap，天然免疫死锁状态，操作保证了原子性
4.分布式锁
在分布式环境下，锁定全局唯一资源，使请求串行化，实际表现为互斥锁，防止重复，解决幂等。
5.悲观锁
在获取数据时加锁，当同时有多个重复请求时其他请求都无法操作
可扩展原则
可扩展原则是必然考虑的因素，从项目架构，数据库设计，技术选型和编码规范等多个方面考虑
1.接口统一，方便集成
2.使用无状态化的应用服务，避免开发后期遇到session共享等数据同步问题
3.使用HDFS等分布式系统，在存储容量不足时迅速通过增加设备来扩容
4.合理设计数据库的分库分表策略，能快速进行数据扩容
5.使用分布式或微服务架构，快速开发并易于增加新的功能模块
6.设计系统时考虑可扩展的各种手段，大幅度提高开发效率
7.通过横向扩展MapReduce的方法，增加节点个数提升并行计算性能
可维护原则
字面理解开发系统方便改正修复系统存在的问题，从以下5个方面说起
1.项目的日志记录功能完善，易于追溯，统计问题（日志是不可避免的）
2.有BugFree等Bug管理工具(名字比较专业，在软件测试课程中使用过，禅道)
3.有丰富的项目文档和注释(夸张的说法有代码一行，注释十行)
4.统一的开发规范(主要就是命名，见名知意，缩进规范)
5.使用模块化的编程模式(微服务搭建就是模块化开发的)
可监控原则
对系统中的流量，性能，服务异常等情况进行实时监控
对项目的关键技术做出性能监控，结合自己的实践，测试和监控情况进行具体的分析
个人总结
上面提及到的CAS算法，以及幂等性原则和重复提交还需要再去理解
写在后面的话：事件结果：现在的时间完全按照自己的规划走下去，所以写下了以上blog 碎碎念：欢迎大家指出blog中的问题，督促笔者进一步改善 |