码迷,mamicode.com
首页 > Web开发 > 详细

网站平台架构演变史(二)

时间:2017-04-24 12:12:21      阅读:161      评论:0      收藏:0      [点我收藏+]

标签:企业   微服务   就会   水平   进一步   保存   架构   微服务架构   服务架构   

上篇文章大致降了网站架构的一个大致发展趋势,这篇咱们讲讲数据库。数据库在大并发的情况下是最容易出现问题的,往往都是由于写操作引发的网站访问缓慢或者崩溃,之前说过12306就是这个问题。

大并发的时候,打个比方,上下班高峰期经常会堵车,我们把并发访问量当做车流量,某个路段路口比作数据库,某路口就这么大,3车道直行,而车流量巨大的时候就会引发大量车缓慢前行甚至不动,这个就是并发,交通瘫痪了嘛,数据库不也是一样瘫痪吗。

技术分享

 

之前我们讲的读写分离,就是一种解决方案,很多网站都是读操作大于写操作的,分开即可,就像车流量一样,转弯的提前在别的路口转弯,直行的不变。

那么当网站再进一步发展的时候,读写分离已经满足不了数据库的性能需求了,这个时候该怎么做呢?

1、分库,根据不同的业务把数据库切分,比如用户相关表和订单相关表分别放在user_db和order_db中,这样的做法可以很有效的减少数据库压力,但是这么做会增加业务的复杂度,比如分布式事务的最终一致性。在微服务架构中这是必须要解决的问题,再次不多说

 

2、表的水平拆分,很多企业都是这么做的,比如淘宝,人家水平拆分根据主键id取模后分别放在不同的表(或者库)中,举个栗子,我们自家的表示这样的

 技术分享

 

日期6位+随机10位字幕数字组合(分布式的根据算法产生的绝对唯一不重复主键),提取前六位数字取模,根据取模的数字来作为保存到不同表(库)中的依据

还有一种水平拆分是定时把一些不用的数据放进别的表中,冷热数据分离,这也是一种做法

3、表的垂直拆分,垂直拆分是指把数据库列,根据某些列被访问的频率高低,来决定,频率高的放在主表,频率低的放在从表,大家都有一个相同的主键,这是主从表的交集,便于管理和操作

好吧,到此,解决数据库瓶颈的手段大致如此,不论分库还是分表,最终的目的都是优化网站的性能。

 

网站平台架构演变史(二)

标签:企业   微服务   就会   水平   进一步   保存   架构   微服务架构   服务架构   

原文地址:http://www.cnblogs.com/leechenxiang/p/6755446.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!