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