标签(空格分隔): 读书笔记
[TOC]
*通过前面的介绍,我们已经了解了分布式系统的相关知识,下面看一下大型网站架构演化及怎么用这个集群的。
看这个的我想都是有些经验的人了,就不啰嗦了,大型网站就是 访问量&数据量 都很大,必须同时具备这两个条件才可以,你整一堆静态页面 每天1000000000000000000000个人访问也不能称之为大型网站。只有当以上两个条件都具备的情况下,你才会有高并发的问题,才需要一个集群来支撑你的业务。
这方面的文章确实不少,给大家介绍几个比较不错的演进过程
宜人贷: http://www.jianshu.com/p/410250e006cb
精品博客(包含很多案例): http://www.hollischuang.com/archives/1036
关于负载均衡session问题的解决方案:
1.使用无状态(cookie)的会话请求
缺点是
安全性:毕竟cookie是可见的。如果要实现安全的cookie就要在技术上改进,比如加密或每次生成一个token等方式来规避不安全问题。
cookie长度限制:这个无解
带宽消耗及性能影响:每次请求都带有session数据,还要解密及设置新token,相对来说肯定对性能有一定影响。
如果对安全性要求不是很高,还是可以选用这种方式。
2.ngxin使用ip轮询的方式(不稳定)
缺点是当使用ip轮询方式式,假如某一ip访问的机器挂了。把这个ip定位到其他机器上,就没有session了。以及nginx会变成一个有状态的节点,内存消耗会更大(不过可以加内存嘛),但是容灾会更麻烦。
3.session同步
现在主流的容器都有session同步功能,比如tomcat。
同步session造成网络带宽消耗,机器越多,消耗越大,相对来说性能也越差。
每台机器都需要保存全部机器的session.这样session数据占用的内容会很严重。
4.使用会话集中管理,如membercache来集中管理回话。
这种是比较常见的实现方式。比以上3种方式都要好,但是也有一定的缺点,比如session存储需要远程读取,会有延时及不稳定性,不过一般我们集群都是部署在内网的,这点可以忽略。另一个问题就是要相应的做好session集中会话管理服务器的容灾工作。假如没有容灾,session会话管理服务器挂了。整个应用就会受到影响。
分库/分表/分区:这里建议采用分区操作,对sql比较友好,对orm层也没有变化。分表分库应为最后的优化手段,毕竟对数据层代码有影响。而且会存在分布式事务这个大麻烦。读写分离:读库与写库分开,现在各种数据库都有这种技术,只不过相应的来说,会有一定的延时性。但是性能提升是比较大的。
对于站内搜索,如果数据量比较大,可以使用做一个搜索组件来代替like,毕竟like效率不是很高。
对于经常需要读很少改的数据,可以通过缓存来提高读取的性能。这部分就不用多说了,主要就是ehcache/redis等各种cache组件。
另一个缓存的应用就是缓存页面,把经常访问的动态页面缓存起来,直接读取缓存,减小服务器的开销。比如ehcahce就可以缓存页面。
缓存使用的好不好的一个指标就是:缓存命中率,如果命中率很低,需要调整代码结构。
总结
总的来说,所有的架构都是经历了从以下这个阶段
1.webapp&database:应用与数据库在一台机器上(all in one)。
2.webapp+database:分离数据库与应用,提高数据读写性能。
webapp+database:负载均衡+多个应用服务器+数据库。
webapp+cache+database:基于第3次改变,增加缓存设置,提高读取性能。5.nginx+n webapp+cache+n database:添加多个数据库,实现读写分离,提高读取性能。
6.基于5的基础上,对数据库进行改造,包括分表分库分区或使用第三方的软件(mycat等)来增强数据库性能。同时对webapp进行拆分,拆分出多个服务中心,每个服务中心负责专门的业务。期间涉及到的技术有(包括但不限于):redis/avtivemq(消息中间件)/mycat/zookeeper/nosql等
其实对于大型网站来说,主要问题就是
1.服务的管理:这个比较麻烦,如果服务多了以后各种接口的调用及服务状态的监控
2.io:对于现在情况来看,我们服务的主要瓶颈还是集中在io层。主要是数据库的读写比较耗费时间,所以解决了这个问题,我想应用的速度是可以更上一层楼的。包括利用适合ssd的数据库,记得国外有个这样的数据库。还有好的中间件,现在的中间件都有较大的性能损耗(30%)。