谈谈业务中使用分布式的场景-分布式开发适应哪些场景

　　首先，需要了解系统为什么使用分布式。

　　随着互联网的发展，传统单工程项目的很多性能瓶颈越发凸显，性能瓶颈可以有几个方面：

　　应用服务层：随着用户量的增加，并发量增加，单项目难以承受如此大的并发请求导致的性能瓶颈。

　　底层数据库层：随着业务的发展，数据库压力越来越大，导致的性能瓶颈。

　　场景1：应用系统集群的 Session 共享

　　应用系统集群最简单的就是服务器集群，比如：Tomcat 集群。应用系统集群的时候，比较凸显的问题是 Session 共享，Session 共享我们一是可以通过服务器插件来解决。另外一种也可以通过 Redis 等中间件实现。

　　场景2：应用系统的服务化拆分

　　服务化拆分，是目前非常火热的一种方式。现在都在提微服务。通过对传统项目进行服务化拆分，达到服务独立解耦，单服务又可以横向扩容。服务化拆分遇到的经典问题就是分布式事务问题。目前，比较常用的分布式事务解决方案有几种：消息最终一致性、TCC 补偿型事务等。

　　场景3：底层数据库的压力分摊

　　如果系统的性能压力出现在数据库，那我们就可以读写分离、分库分表等方案进行解决。

　　(二)Session 分布式方案

　　基于 nfs(net filesystem) 的 Session 共享

　　将共享服务器目录 mount 各服务器的本地 session 目录，session 读写受共享服务器 io 限制，不能满足高并发。

　　基于关系数据库的 Session 共享

　　这种方案普遍使用。使用关系数据库存储 session 数据，对于 mysql 数据库，建议使用 heap 引擎。这种方案性能取决于数据库的性能，在高并发下容易造成表锁(虽然可以采用行锁的存储引擎，性能会下降)，并且需要自己实现 session 过期淘汰机制。

　　基于 Cookie 的 Session 共享

　　这种方案也在大型互联网中普遍使用，将用户的 session 加密序列化后以 cookie 的方式保存在网站根域名下(比如 taobao.com)，当用户访问所有二级域名站点式，浏览器会传递所有匹配的根域名的 cookie 信息，这样实现了用户 cookie 化 session 的多服务共享。此方案能够节省大量服务器资源，缺点是存储的信息长度受到 http 协议限制;cookie 的信息还需要做加密解密;请求任何资源时都会将 cookie 附加到 http 头上传到服务器，占用了一定带宽。

　　基于 Web 容器的 Session 机制

　　利用容器机制，通过配置即可实现。

　　基于 Zookeeper 的分布式 Session 存储

　　基于 Redis/Memcached 的 Session 共享存储

　　这些 key/value 非关系存储有较高的性能，轻松达到 2000 左右的 qps，内置的过期机制正好满足 session 的自动实效特性。

　　转自：有梦想的咸鱼