前几天跟一个朋友聊了一些关于网站缓存分布式的一些东西，发现自己的知识还是太过贫瘠。理论+协议，这是现在我亟待加强的。这个周末买了两本关于分布式网站的书，本着好记性不如烂笔头，便有了这样一系列的文章。希望一同分享，也请多指教。
code less, play more!
前言
这个世界上没有哪个网站从诞生起就是大型网站；也没有哪个网站第一次发布的时候就拥有庞大的用户，高并发的访问，海量的数据；大型网站都是从小型网站发展而来。网站的价值在于它能给用户提供什么家宅，在于网站能做什么，而不在于它是怎么做的，所以网站在小的时候就去追求网站的架构是舍本逐末，得不偿失的。小型网站最需要做的就是为用户提供更好的服务来创造价值，得到用户认可，活下去，野蛮生长。
大型网站软件系统的特点
- 高并发，大流量
- 高可用
- 海量数据
- 用户分布广泛，网络情况复杂
- 安全环境恶劣
- 需求快速变更，发布平频繁
- 渐进式发展
大型网站的发展历程
- 初始阶段的网站架构
最开始没有多少人访问，所以应用程序，数据库，文件都在同一台机器上。
-
应用服务器和数据服务分离
应用和数据分离之后，一般需要三台服务器。应用服务器，文件服务器和数据库服务器，这三种服务器对于硬件要求各不相同。
- 应用服务器：更强大的CPU
- 数据库服务器：更快速的磁盘和更大的内存
- 文件服务器：容量更大的硬盘
-
使用缓存改善性能
网站的访问也遵循二八定律：80%的业务集中在20%的数据上。因此可以把这一小部分数据缓存在内存中，减少数据库的访问压力。
网站的缓存可以分为两种：
- 本地缓存：缓存在应用服务器上。本地缓存访问速度快，但是受制于内存限制，缓存数量有限，而且也会出现和应用程序争抢内存的情况。
- 远程分布式缓存：以集群的方式，缓存在大内存的专用缓存服务器。可以在理论上做到不受内存容量限制。
- 使用应用服务器集群提高并发能力
当一台服务器的处理能力和存储空间不足的时候，不要企图更换更强大的服务器。对于大型网站来说，不管多么强大的服务器，都满足不了网站持续增长的业务需求。此时就可以考虑集群的方式，通过负载均衡调度服务器，可以将来自用户的请求分发到应用服务器集群中的任何一台服务器上。
- 数据库读写分离
使用缓存后，大部分的数据读操作访问都可以不通过数据库完成，但是仍有部分读操作（如缓存过期，缓存不命中）和全部的写操作需要访问数据库。
目前大部分数据库都提供主从热备的功能，在写数据的时候，访问主库，主库通过主从复制机制将数据更新同步至从数据库，在读的时候就可以通过从数据库获取数据。
-
使用反向代理和CDN加速网站响应
在《web性能权威指南》中有讲到，网站性能的瓶颈，大部分时间都浪费在TCP的握手和传输上。因此可以通过CDN和反向代理的方式来加快响应。
CDN和反向代理的本质都是通过缓存，不同的主要是：
- CDN部署在服务器器上的机房，用户在请求时，从距离自己最近的机房获取数据。
- 反向代理是部署在中心机房，用户请求到达中心机房之后，首先访问的服务器是反向代理的拂去其，如果反向代理服务器中缓存着用户请求的额资源，就将其返回给用户。
- 使用分布式文件系统和分布式数据库系统
随着业务的发展，依旧不能满足的时候，就采用分布式的文件和分布式的数据库系统。
分布式数据库是数据库拆分的最后手段，只用在单表数据规模特别庞大的时候才使用。更常用的拆分手段是业务分库，将不同的业务数据存储在不同的数据库中。
- 使用NoSQL和搜索引擎
对数据检索和存储越来越复杂的时候，就可以采用一些非关系型数据库如HBase和非数据库查询技术如ElasticSearch等等
- 业务拆分
业务场景复杂的时候，一般讲整个网站业务分为不同的产品线，如首页，订单，买家，卖家等等。
技术上也会根据产品线划分，将一个网站分为许多不同的应用，每个应用独立部署维护，应用之间可以通过一个超链接建立联系，也可以通过消息队列进行数据分发，当然最多的还是通过访问同一个数据存储系统来构成一个关联的完整系统。
- 分布式服务
随着业务越拆越小，存储越来越大，维护越来越困难。此时就可以将相同业务操作的提取出来，独立部署。应用系统只需要管理用户界面，通过分布式服务调用共同的业务服务完成具体的业务操作。也就是最近概念越来越火的——微服务。
- 云计算
大型网站架构解决了海量数据库管理和高并发事务处理，可以将这些解决方案应用到网站自身以外的业务上。现在像阿里云，亚马逊等云计算平台，将计算作为一种基础资源出售，中小网站不需要关系技术架构等问题，只需要按需付费，就可以使网站随着业务的增长获得更大的存储和计算资源。
- 未来
未来还能变成什么样子，我也不清楚，也许以后都不是开发人员来维护了，所有的这些都是AI来完成，程序员要做的就是如何完善AI。也许AI发展到最后，人类都不需要存在了吧。
结语
网站的技术是为业务而存在的，除此以外毫无意义。在技术选型和架构设计中，脱离业务发展实际，一味的追求新技术，可能会把技术发展引入一个歪路。
技术是用来解决业务的问题，而技术不可能将所有问题都解决掉，涉及业务自身的问题，还是要通过业务手段去解决。
