标签：企业 微服务 就会 水平 进一步 保存 架构 微服务架构 服务架构
上篇文章大致降了网站架构的一个大致发展趋势，这篇咱们讲讲数据库。数据库在大并发的情况下是最容易出现问题的，往往都是由于写操作引发的网站访问缓慢或者崩溃，之前说过12306就是这个问题。
大并发的时候，打个比方，上下班高峰期经常会堵车，我们把并发访问量当做车流量，某个路段路口比作数据库，某路口就这么大，3车道直行，而车流量巨大的时候就会引发大量车缓慢前行甚至不动，这个就是并发，交通瘫痪了嘛，数据库不也是一样瘫痪吗。
之前我们讲的读写分离，就是一种解决方案，很多网站都是读操作大于写操作的，分开即可，就像车流量一样，转弯的提前在别的路口转弯，直行的不变。
那么当网站再进一步发展的时候，读写分离已经满足不了数据库的性能需求了，这个时候该怎么做呢？
1、分库，根据不同的业务把数据库切分，比如用户相关表和订单相关表分别放在user_db和order_db中，这样的做法可以很有效的减少数据库压力，但是这么做会增加业务的复杂度，比如分布式事务的最终一致性。在微服务架构中这是必须要解决的问题，再次不多说
2、表的水平拆分，很多企业都是这么做的，比如淘宝，人家水平拆分根据主键id取模后分别放在不同的表（或者库）中，举个栗子，我们自家的表示这样的
日期6位+随机10位字幕数字组合（分布式的根据算法产生的绝对唯一不重复主键），提取前六位数字取模，根据取模的数字来作为保存到不同表（库）中的依据
还有一种水平拆分是定时把一些不用的数据放进别的表中，冷热数据分离，这也是一种做法
3、表的垂直拆分，垂直拆分是指把数据库列，根据某些列被访问的频率高低，来决定，频率高的放在主表，频率低的放在从表，大家都有一个相同的主键，这是主从表的交集，便于管理和操作
好吧，到此，解决数据库瓶颈的手段大致如此，不论分库还是分表，最终的目的都是优化网站的性能。
标签：企业 微服务 就会 水平 进一步 保存 架构 微服务架构 服务架构
原文地址：http://www.cnblogs.com/leechenxiang/p/6755446.html
