写在前面的话：时间：2021.12.25 地点：陕西西安（居家办公）
|
续前文：系统分析原则
引入正题之系统设计要点
前文提到未雨绸缪总是正确的选择，对于开发来说，在系统分析阶段，就应该尽可能的规避项目开发中可能遇到的问题，几个经典的例子来说
session共享问题--》优先考虑无状态服务--》技术选型和数据库设计--》缓存穿透与雪崩问题(redis里的经典问题)--》总之：根据项目的实际需求与成本预算找到最合适的方案(性价比最高)
Session共享问题
session是服务器端用于保存客户端信息的重要对象，单系统中的session可以直接保存在内存中，在分布式系统，多个不同节点共享session对象提出下面三个解决方案
1.Session Replication(复制)
节点过多时，复制导致严重冗余 引起广播风暴，增大网络开销
2.Session Sticky(adj粘性的，n告事贴)
通过Nginx标记，弊端就是某个服务节点宕机，该节点的所有session对象丢失
3.独立session服务器(有图有真相)
优先考虑无状态服务
对于无状态服务和有状态服务的理解有状态服务指的是不同的应用服务与用户状态有着密切的关系(字面理解就是保存了用户session)
无状态服务的优势
1.数据同步
“有状态服务”为了在不同的服务节点之间共享数据，必然会数据同步(CPU/内存损耗，网络延迟，数据冗余)
“无状态服务”不需要数据同步
2.快速部署（数据同步的基础）
上图是”状态“的存储方式
一套快速扩容的系统
最后还是强调物极必反，小型项目或者仅有一个服务的项目中，就可以采取”有状态服务“来降低开发难度，缩短开发周期
技术选型原则与数据库设计
技术选型： 考虑待选技术的性能和技术的安全性
设计步骤：
高可用Redis集群的搭建，读写分离降低并发写操作的冲突，通过主从同步就行数据备份，通过哨兵模式在Master挂掉后，进行选举
搭建双Master的Mysql集群，通过主从同步做数据备份
通过Mycat对大容量进行分库/分表，并控制读写分离
通过Haproxy搭建Mycat集群
通过Keepalived搭建Haproxy集群，并通过心跳检测机制防止单节点故障，通过Keepalived生成一个VIP对象与Redis连接
缓存穿透与缓存雪崩问题
缓存在一定程度上缓解高并发造成的性能问题，缓存自身两个典型的问题
1：缓存穿透
了解了穿透原因之后的对应策略
其实缓存穿透的解决策略就是拦截，第三种方法建立数据标识仓库
2：缓存雪崩
Redis失效导致的
综合因素
参照前面介绍的系统设计原则和设计要点，设计一个在项目成本内（小于预算）的切实(就是有能力干活，SpringBoot开发更简单，但是我只会SSM，淦)，性价比最高（性能参数如何优化，方便客户反馈）并能提供方便维护的系统
自我总结
根据流程控制可以更方便理解知识点，但是好像只是不进脑子，后面小节讲了大型系统的演进与大型架构的设计以及分布式ID生成器之后的详细知识点会有案例讲解，比较友好
|
8560
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
