分布式系统开发常见问题-1. session的复制与共享 2. 分布式缓存的设计

1. session的复制与共享

在web应用中，为了应对大规模访问,必须实现应用的集群部署.要实现集群部署主要须要实现session共享机制,使得多台应用服务器之间会话统一, tomcat等多数主流web服务器都采用了session复制以及实现session的共享. 但问题仍是很明显的：

在节点持续增多的状况下,session复制带来的性能损失会快速增长.特别是当session中保存了较大的对象,并且对象变化较快时,性能降低更加显著.这种特性使得web应用的水平扩展受到了限制.

 

session共享的另外一种思路就是把session集中起来管理,首先想到的是采用数据库来集中存储session,但数据库是文件存储相对内存慢了一个数量级,同时这势必加大数据库系统的负担.因此须要一种既速度快又能远程集中存储的服务：memcached

使用memcached来存储session有两种方案:

(1)直接经过tomcat6的扩展机制实现.

Reference: http://www.javaeye.com/topic/81641

(2)经过本身编写filter实现.

考虑到系统的扩展,咱们采用这种方案.这样可使session共享机制和中间件脱钩.

Reference: http://www.javaeye.com/topic/82565

主要思路:

1)继承重构HttpServletRequestWrapper,HttpSessionWrapper类,覆盖原来和session存取相关的方法呢,都经过SessionService类来实现.

2)使用filter拦截cookie中的sessionId,经过sessionId构造新的HttpServletRequestWrapper对象,传给后面的应用.

3)SessionService链接memcached服务,以sessionId做为key,存取的对象是一个map.map的内容即为session的内容.

 

使用过程注意几个问题和改进思路： 
一、memcache的内存应该足够大，这样不会出现用户session从Cache中被清除的问题(能够关闭memcached的对象退出机制)。 
二、若是session的读取比写入要多不少，能够在memcache前再加一个Oscache等本地缓存，减小对memcache的读操做，从而减少网络开销，提升性能。 
三、若是用户很是多，可使用memcached组，经过set方法中带hashCode，插入到某个memcached服务器

 

(3)使用memcached-session-manager管理session

Reference: http://www.iteye.com/topic/1125301

对于session的清除有几种方案:

(1)能够在凌晨人最少的时候，对memcached作一次清空。

(2)保存在缓存中的对象设置一个失效时间,经过过滤器获取sessionId的值,按期刷新memcached中的对象.长时间没有被刷新的对象自动被清除.(相对复杂,消耗资源)

2. 分布式缓存的设计：在多台Node的环境下，产生的缓存以及缓存的变化，如何处理？

To be continued...

3. 数据库的sharing, 当数据量愈来愈大，数据须要迁移时，对不一样的分库，分表（区），业务数据处理层如何可以适应底层的变化?

使用DDL：Sharding扩容方案-全局增量+局部hash散列

一个大型的互联网 应用必然会通过一个从单一DB server,到Master/salve,再到垂直分区（分 库），而后再到水平分区（分表，sharding）的过程(随着用户量的不断增长，你会发现系统中的某些表会变的异常庞大，好比好友关系表，店铺的参数配置表等，这个时候 不管是写入仍是读取这些表的数据，对数据库来讲都是一个很耗费精力的事情)，而在这个过程当中，Master/salve 以 及垂直分区相对比较容易，对应用的影响也不是很大，可是分表会引发一些棘手的问题，好比不能跨越多个分区join查 询数据，如何平衡各个shards的 负载等等，这个时候就须要一个通用的DAL框架来屏蔽底层数据存储对应用逻辑的影响，使得底层数据的访问对应用透明化。

拿淘宝目前的状况来讲，淘宝目前也正在从昂贵的高端存储（小型机+ORACLE）切换到MYSQL,切 换到MYSQL以 后，势必会遇到垂直分区（分库）以及水平分区（Sharding）的问题，所以目前淘宝根据自 己的业务特色也开发了本身的TDDL(Taobao Distributed Data Layer)框架，此框架主要解决了分库分表对应用的透明化以及异构数据库之间的数据复制。

淘 宝网采用什么技术架构来实现网站高负载的呢？淘宝的总体架构使用了以下措施来应对：一应用无状态(淘宝session框架)；二有效使用缓存 (Tair)；三应用拆分(HSF)；四数据库拆分(TDDL)；五异步通讯(Notify)；六非结构化数据存储(TFS,NOSQL)；七监控、预警 系统；八配置统一管理。

http://code.taobao.org/p/tddl-dynamic-datasource/wiki/index/

4.  铁道部网站为什么登陆会挂，进入以后就不会。

登陆的时候，由于没有足够的服务相应用户的查询请求，负载均衡不够，服务器很是繁忙，致使没法登陆。登陆进入的人少了，那登陆进去的用户基本上在网站的承载范围内，因此登陆以后只会慢，不会挂掉。

使用CDN, 足够的服务器集群，负载均衡，缓存存取用户信息，经过测试让系统容量可以达到2kw级别，便可让更多的用户登陆进系统。真正的问题不在登陆，而在登陆以后的对票的查询与巧夺。查询能够经过单独的查询集群服务来解决。最困难的是最有限的资源的争夺（1.火车票的状态是实时计算，实时更新的；2.火车票资源稀缺，须要同线下数以万计的购票点、电话订票等进行互斥。每张火车票都是独一无二的，网络售票只是数以万计的购票终端的一个终端而已，须要跟其余售票系统保持数据一致性）。

solution 1: 设定容忍度: 绝对不能两我的订到同一张票，而看到有票，而点击了下订单又说没票了这种失误是能够容忍的。

solution 2: 排队，异步告知前面多少人，轮到以后，规定时间下单（查询须要的票，下单到的票锁住，timeout则踢出）

solution3: 100w有效点击的用户，随机摇出可否负载的用户数（10w）

点击订票以后，进入前置分析机，分析机负责计算背后的机器能负载多少用户下订单。好比目前有1百万人同时点击了订票，而背后只能负载10万人，那么出现一个随机摇号程序，摇出10万人，其余人返回 “系统繁忙，稍后重试”的提示。这10万人被负载在10台机器上，能够进行查询，当点击指定车票（标记为ClickSelectedTicket）后，根据车票被分散到不一样的机器上（实际上是MapReduce的思想）。好比有1万人被定位到要订票T1，系统扔出900张T1票，留100张容错（随着系统逐步稳定，可减小容错票数），而后你们抢锁，采用乐观离线锁。在最终提交订单时检测。