应用集群时，Session解决方法
-
Session Sticky：让负载均衡器根据会话标识选择对应的服务器，原来的其他设备方案基本不用变动，但缺点是负载均衡器就会变成有状态的节点，内存消耗会更大，容灾更麻烦。
-
Session Replication：不同服务器之间进行Session数据同步，这样负载均衡器不需要改变，无论是哪个服务器相应都有着相同的Session。问题则是同步Session数据造成网络带宽的开销，以及随着服务器的增多Session数据也会急剧增多。
-
Session数据集中存储：所有Session都集中存储到同一个地方，不同服务器之间不需要进行Session数据同步，都从同一个地方获取Session数据。问题也很明显，若存储Session的机器出了问题，那会影响整个应用；另外读写Session会引入网络操作，可能会存在时延。
-
Cookie Based：将Session存储在Cookies中，这样就没有外部系统获取和读写Session数据的网络时间和不稳定性。但这个存在几个严重问题：Cookie长度限制，安全性问题，带宽消耗，以及性能影响（每次HTTP请求和相应的头部数据增多）。
关于读写分离
一个大型应用通常都是读多写少，此时可以进行读写分离，即增加一个读“源”，需要解决的问题是，怎么把数据复制到这个源中，减少各种时延。
这里记录一下，搜索引擎，其实有点像读库，所不同的，搜索引擎是构建索引，构建索引不仅仅是简单的数据复制。
数据库拆分
垂直拆分
把数据库中不同业务数据拆分到不同的数据库中，可以根据不同业务特点进行优化。增加了多个数据源的配置，但是带来的麻烦是多个数据连接池的隔离。解决方案有：1. 使用分布式事务，但其性能明显低于单机事务；2. 去掉事务或不去追求事务支持，改为表关联查询即可。
水平拆分
数据水平拆分是指把同一个表中的数据拆分到两个数据库中，之所以这么做是因为某个业务的数据表的数据量或更新量可能达到单个数据库的瓶颈，拆分到两个或多个数据库中，可以很好解决数据量以及写入量增长的问题。带来的影响则是由于数据分布在不同数据库中，SQL查询时，需要判断在哪个数据中查询，量大分页查询也难处理；此外，自增字段不能简单实用了。
应用处理
随着业务不断扩展，应用功能会越来越多，应用也会越来越大，这个时候为了避免应用持续变大，可以对应用进行拆分。
应用拆分
-
根据业务特性进行拆分，比如主要的业务功能分为三大部分：交易，商品和用户。这个时候可以把应用拆分成以交易和商品为主的两个应用，而涉及到用户的地方，可以暂时交给其中一个系统完成。
-
此外还可继续根据功能继续拆分，例如用户注册、用户登录、用户信息维护变成三个系统
服务化
各种功能由对应的服务中心提供服务，另外中间业务功能之间访问不仅是单机内部方法调用，而且支持远程的服务调用，其次主要代码都放在服务中心，第三数据库交互也是放在各个服务中心，而上层的Web系统则不需要关心业务逻辑的实现，最后，每个服务中心和Web应用都可以各自小团队进行维护，能够更好保证稳定性。
消息中间件
应用A和应用B通过消息中间件进行信息通信，好处是实现异步和解耦操作。
中间件
- 远程过程调用和对象方法中间件：解决分布式环境下互相访问的问题，是应用服务化的基础
- 消息中间件：解决应用之间消息传递，解耦和异步的问题
- 数据访问中间件：解决应用访问数据库的共性问题
