大型网站架构改进历程：存储的瓶颈

大型网站定义

从网站的技术指标角度考虑这个问题人们很容易犯一个毛病就是认为网站的访问量是衡量的指标，懂点行的人也许会认为是网站在单位时间里的并发量的大小来作为指标

大型网站是技术和业务的结合，一个满足某些用户需求的网站只要技术和业务二者有一方难度很大，必然会让企业投入更多的、更优秀的人力成本实现它，那么这样的网站就是所谓的大型网站了。

服务器部署

分开部署的Web应用服务

Session机制

保持不同物理部署服务器之间的session同步问题

解决session的问题的本质也就是解决session的存储问题，其本质也就是解决网站的存储问题，一个初建的网站在早期的运营期需要解决的问题基本都是由存储导致的。

大型网站最常遇到的存储瓶颈

网站在高并发下挂掉的原因90%都是因为数据库不堪重负所致

升级网站能力的第一步工作就是提升数据库的承载能力

如何解决海量数据下的“读”问题

对于海量数据的读我们可以采用搜索技术，我们可以将数据库的数据导出到文件里，对文件建立索引，使用倒排索引技术来检索信息，我们看到了百度，谷歌有整个互联网的信息我们任然能很快的检索到数据，搜索技术是解决快速读取数据的一个有效方案，不过这个读取还是和数据库的读取有所区别的，如果用户查询的数据是通过数据库的主键字段，或者是通过很明确的建立了索引的字段来检索，那么数据库的查询效率是很高的，但是使用网站的人跟喜欢使用一些模糊查询来查找自己的信息，那么这个操作在数据库里就是个like操作，like操作在数据库里效率是很低的，这个时候使用搜索技术的优势就非常明显了，搜索技术非常适合于模糊查询操作。

一个解决大型网站数据瓶颈的一个脉络了，具体如下：

单库数据库-->数据库读写分离-->缓存技术-->搜索技术-->数据的垂直拆分-->数据的水平拆分

大家如何实现分布式事务，他想要知道的分布式事务是有没有一种技术能像我们操作数据库或者是jdbc那样一个commit，一个rollback就搞定，但是现实中的分布式事务比commit和rollback复杂的多，不可能简单的让我们写几个标记就能实现分布式事务，

但是我们解决分布式事务大多数从业务角度来解决的，而没去选择纯技术手段，因为技术手段太复杂难以控制。

总结下本文的内容，具体如下：

1. 大型网站解决存储瓶颈的问题，我们要找准存储这个关键点，因为数据库其实是存储和运算的组合体，但是在我们这个场景下，存储是第一位的，当存储是瓶颈时候我们要狠下心来尽量多的抛弃数据的计算特点，所以上文中我提出我们数据库就不要滥用计算功能了例如触发器、存储过程等等。

2. 数据库剥离计算功能不代表不要数据的计算功能，因为没有数据的计算功能数据库也就没价值了，那么我们要将数据库的计算功能进行迁移，迁移到程序里面，一般大型系统程序和数据库都是分开部署到不同服务器上，因此程序里处理数据计算就不会影响到数据库所在服务器的性能，就可以让安装数据库的服务器专心服务于存储。

3. 我们要尽一切可能的把数据库的变化对服务层的影响降到最低，最好是数据库做拆分后，现有业务不要任何的更改，那么我们就得设计一个全新的数据访问层，这个数据访问层将数据库和服务层进行解耦，任何数据库的变化都由数据访问层消化，数据访问层对外接口要高度统一，不要轻易改变。

4. 如果我们设计了数据访问层来解决数据库拆分的问题，数据访问层加上数据库其实就组合出了一个分布式数据库的解决方案，由此可见拆分数据库的难度是很高的，因为数据库将拥有分布式的特性，而分布式开发就意味开发难度的增加。

5. 对于分布式事务的处理，我们尽量要从具体问题具体分析，不要一感觉这个事务操作本质是分布式事务就去寻找通用的分布式事务技术手段，这样的想法其实是回避困难的思想，结果可能会是把问题搞得更加复杂。