分布式问题总结

1.session共享问题

　　1. session复制

　　　　将session复制每一台服务器上，缺点：每台机器需要网络通信，需要网络开销，有延迟；同时当服务器太多时出现瓶颈，每台都需要备份session，出现内存不够用的情况。早期的项目有些会这样使用

　　2. session绑定

　　　　利用hash算法，将统一ip的用户，分配到同一服务器上，如ngnix的ip_hash负载均衡算法，缺点，当用户ip发生变化，或者服务器宕机时，用户需要重新登陆

　　3. session服务器

　　　　将session信息记录在一台服务器上。缺点需要保证服务器的稳定性

　　　　实现：1. 修改sessionManager，如：shiro里

　　　　 org.apache.shiro.spring.web.ShiroFilterFactoryBean -> securityManager -> sessionManager -> sessionDAO
　　　2. 通过spring-redis-session包实现

2.分布式系统中的缓存

　　a. CDN：缓存一些静态资源，距离用户最近的网络提供商提供。

　　b. 反向代理：缓存静态资源，访问网站数据中心前访问。如ngnix

　　c. 本地缓存：缓存在本地的访问内容，常用的本地缓存开源框架有EhCache。

　　d. 分布式缓存：缓存在分布式缓存集群中，常用的分布式缓存开源框架有redis，memcache。

3. 缓存更新/删除

　　1. 再修改数据库时，是更新还是删除缓存，主要看需要更新缓存的代价大小，如果代价小，此时我们应该更倾向于更新缓存，以保证更高的缓存命中率。否则，删除缓存

　　2. 删除缓存 -> 更新数据库，还是 更新数据库 -> 删除缓存 ？？？

　　　　删除缓存 -> 更新数据库，可能带来的问题是在并发情况下，1线程删除缓存，2线程执行读取操作，缓存未命中重新查询，再将缓存保存；然后1线程再执行更新数据库。此时缓存中的便出现了脏数据。

　　　　更新数据库 -> 删除缓存，可能带来的问题是 a. 更新数据库成功后，更新缓存失败;b. 1线程更新数据库，2线程执行读取操作，缓存未命中重新查询完成，1线程更新数据库成功，清除缓存，2线程此时再保存缓存（此概率极低）

　　3. 更新缓存的策略选取需要根据实际情况，个人理解，当查询的并发量比较高时，优先选取 更新数据库 -> 删除缓存。当没有什么高并发时，删除缓存失败的可能性会更大，此时选择 删除缓存 -> 更新数据库。

　　4. 为优化 删除缓存 -> 更新数据库方案，有人给出了其他解决方法：https://blog.csdn.net/qq_27384769/article/details/79499373

　　5. 从上述可知，上面的俩种方案不能确保缓存的准确性，因此我们需要一些辅助促使

　　　　a. 每天定时更新缓存（在半夜）

　　　　b. 设置缓存失效时间（注意缓存雪崩）

4. 分布式事务

　　太复杂，待完善

5. 分布式锁

转载于:https://www.cnblogs.com/jaxlove-it/p/9883273.html