| 编辑推荐: |
文章讲解什么什么场景适合用分布式架构，分布式数据库特点，分布式数据库——shard，分布式最大的问题——分布式事务，希望对您有所帮助,
本文来自博客园，由火龙果软件Delores编辑、推荐。 |
|
自从谷歌提出分布式这个概念,这个玩意太火了,但是并不是所有的业务场景都适合用分布式的
什么场景适合用分布式架构？
网易分布式用的最好的两个项目：网易考拉 && 网易云音乐(歌单库单表百亿以上记录、评论库)
快递行业
微信红包
其他业务都是有时间维度的,可能只需要存3个月的在线数据,算下来也就2kw,那为什么还要做分布式架构呢？
所以不要迷信分布式架构和分库分表
tips：
单台服务器几千qps没必要分,两三万的话可以分
Ⅰ、分布式数据库特点
优点
可用性提高
可扩展性提升(扯淡,MySQL现在4个节点扩8个节点怎么办？数据库不是redis,redis里面内存数据可以丢掉,甚至redis单线程的做这些都好弄,MySQL并不是,8扩12的话,原来的数据都要打散一遍,原来8个机器,hash8个,现在变12个,数据全部打散,如果8*500G,4T数据打散到12个节点,怎么打散,这么多表)，MySQL可扩展性的提升是很难达到的,我们借助另外一些手段来做扩展性，为什么mongodb,redis,tidb扩展性是好的,因为他们的分片策略更好(也有缺点),是未来比较好的模式,但是在关系型数据库中很难实现,对MySQL内核和中间件的改造太大了
某些情况下吞吐率提升显著 ---大大的问号,只有某些场景才会显著提升，
原来一台机器,拆成八台机器,那就性能提升八倍？这是不存在的
缺点
依赖中间件(不依赖中间件就要在业务层做),业界基本上找不到一个好的中间件,mycat可以用,但是生产上不建议
SQL语句支持不足(中间件支持的sql非常有限,多表join,子查询,派生表这些估计玩不转,mongodb,redis,tidb不做这些)
运维复杂度提高
某些情况下性能下降巨大
Ⅱ、分布式数据库——shard
2.1 shard相关概念
A database shard is a horizontal partition(水平分区) of data in a database. Each individual partition is referred to as a shard or database shard. Each shard is held on a separete database server instance,to spread load.
sharding和分区的异同
相同：打散数据
不同：打散的数据可能不在同一实例上
总结：sharding的实现非常复杂
举个栗子
orders表,根据日期做分区,每个月一张订单表,还是在一台MySQL上
做分片的话,把一张表,分到四台MySQL上去
在分区中：
这个id叫做分区键
在shard中：把这个分区键叫作均衡字段
把id 作hash,%4 来分到四个机器上,把date 作range也可以
如果根据order_key分了四个机器
| select * from
orders where order_key = ? |
这样性能就提升了
怎么找到这个机器呢：
法1：业务层控制,根据分区规则搞,如果order_key是int类型,那就%4,根据结果下发到对应的Datanode(ip)
法2：中间件,client不用关心后端的分库规则,均衡字段这些,client直接通过MySQL协议访问中间件,中间件自动帮你计算该访问哪个节点,sql的改写由中间件来做,像我们上面这个sql就不用改写,只要转一下ip就行
两个问题：
两种方法：哪个性能更好,为什么？
法1更好,直接连数据库,法2多了一层,中间件的优势在于,开发人员更方便写代码,就和直接连数据库一样用,其他事情都交给中间件
业务里面永远都是只有这么一个简单的需求嘛？如果根据其他字段查询呢？会有上面问题呢？
那就所有的分片都要找一遍,你加N多个节点,这样还叫可扩展吗？节点越多,性能越差了都,和分区表的是一样的道理,orders_partition表中可以explain看下两种情况,走索引的话,1亿的数据量下,和1kw数据量下速度是一样的,你分十个片没什么意义
2.2 做shard的三个原则
尽可能大部分的业务逻辑都是根据均衡字段,至少百分之80%,更改分布式数据库中的均衡字段非常麻烦,必须一开始就规划号表的均衡字段
如果不能选择有效的均衡字段,这张表就不要进行Shard,作为全局表
如果业务选择不出有效率的均衡字段,那么进行分布式数据库的改造也将是徒劳的
tips：shard一般用hash打散,平均的,如果没有打散就是均衡字段没选好,可以选择用多个字段作均衡字段
2.3 看看别人的业务怎么选择均衡字段的
你平时怎么逛淘宝的？
点开淘宝,所有的查询都是买家查询,你能查你老婆买了哪些东西吗？所有的查询都是根据自己的id来查(登陆是通过用户中心来登陆的)
下单了,订单里有userid,订单明细中也有userid,登陆到淘宝,查最近一些订单信息,购买记录,也是根据userid来查的
所以电商的表结构设计,有张user表,用来存用户信息的,里面有个userid
又有一个orders表,订单表里面也有个userid
还有个orderline表,一个订单里下了多少个商品,里面也有个userid
可能还有个favorite表,里面也有一个userid
coupon表,还是有个userid
综上,所有买家的数据都有一个userid的字段,这时候 上面这些表就可以根据userid放到不同的shard中
这意味着什么呢？一个用户的所有信息是在一个分片上的,是不会跨分片的,不存在一个查询要查很多个分片的
所以淘宝的业务是非常容易做扩展的,只要加机器,把数据打散,就是可扩展的
所以对于电商的业务来说,有个非常好的维度叫买家维度,所有的查询基本上都是根据买家id
那网易云音乐的歌单又是怎么弄的呢？
也是userid啊,哈哈,看自己的歌单,看别人的歌单,都是用的userid
快递行业用的是什么？
运单号
微信红包的均衡字段是什么？
也是userid,哦嚯
上面所有的都要用中间件,一般用mycat
Ⅲ、分布式最大的问题——分布式事务
3.1 微信红包案例
user<--->user<--->user
中间件
client |
如果一台机器
begin;
update user set money
= money - 100 where userid
= xxx;
update user set money
= money + 100 where userid
= xxx;
commit; |
那走分布式事务的话,很有可能这两个userid不在同一个分片里面
这个事务就变成了分布式事务,首先,mycat不支持分布式事务,但是这么写是支持的
意味着着不是一个原子操作,变成了两个事务分到两个分片上去,做不到原子性,所以千万不要把mycat用在关键的业务,特别是跟钱打交道的
现在业界的中间件,除了淘宝和网易貌似还没有什么中间件支持分布式事务的,那怎么办呢？
分布式事务改为单个事务,之前提过的补偿机制,做一个message表,update的时候往message表中插入消息,另一张表,查看消息,然后update,最后把消息置为已接收
这时候还需要中间件吗？no！这也叫一种柔性事务
3.2 用户下单案例
orders表,三个分片,userid作均衡字段,还有个表,叫stock(库存)
下单的逻辑就变得不一样了,看tpcc样例
begin;
先锁定库存
insert into orders
insert into orderline
update stock set count
= count - 1 where itemid
= ？
update
...
xxx
...
commit; |
orders表分库分表了,stock表没有userid这东西,所以stock表叫全局表,我们该怎么放,可以放到单独的实例上,也可以放到其中的一个分片上,甚至可以根据skuid去做shard
每个MySQL是用来存分片的,但并不要求一个分布式集群中所有的表均衡字段是一样的,业务只要知道怎么存的就行,均衡字段是什么,怎么访问,自己知道就行,对于中间件来说有个元数据库来存这些均衡字段
这时候这个流程就是分布式的了,淘宝网易的中间件可以支持这个,如果stock做了分片就讨厌了,一个订单可以有很多件商品,很多个库存要修改,涉及的节点可能就多了,不像转账了,所以订单表放到消息队列(mq)中做了
要下单的话,先放到mq中,后面很多worker线程,拿到这个消息然后去消费
所以,现在打开京东,天猫这些,下一个单之后,状态显示为出库中,什么叫出库中？
出库中就表示,我现在这个下单,只是把业务逻辑丢到消息队列中,至于消息队列后面能不能成功并不知道,如果库存不够会告诉你出库失败,然后把你这个下单过程回滚掉
所以经常下单成功,出库失败,不是1111,一般都不会有问题,1111的时候就不一定了,实时库存代价太大了
3.3 小结
到现在为止,还用得着中间件嘛？不是可以不用,而是建议不用,因为用了中间件,你避免不了分布式事务,很多核心业务有风险的
根据userid来扩展,做查询没问题啊,但是对于数据库来说,分库分表最难的点在于事务化和持久化,而不是select,甚至select放到redis里都可以
分布式事务到最后都用了消息表和消息队列,业务逻辑都丢到消息里,后面消费线程慢慢消费,出错了,就回滚,关闭订单,订单表中有个状态字段,可见,不可见,成功,没成功,都是通过业务来控制的
微信红包用的就不是中间件,淘宝的下单过程也没有用中间件做,存在分布式事务,性能不好
用分布式事务的协调器来做的,淘宝最早提出tcc,现在基于这个封装了一堆东西了都
所以中间件这东西很危险不要想的太多了,如果用了中间件,那也是个很简单的东西,淘宝,微信核心业务都不用中间件,所有的访问都是业务控制的。
建议：
如果分库分表,最好让业务控制,而不要用中间件,用了中间件这个活儿就是你的,说难听点,就是甩锅,以后出了问题就跟我没关系,第二点,核心业务,中间件不支持分布式事务,保证不了事务性和持久性,第三点,中间件性能真的不行,即使用了ddb,一个订单三个商品垮了好多个节点,双十一能接受吗？不要迷信中间件
但是,快递行业真的很适合中间件,因为快递行业没有很强的事务性要求,就是一个个运单,这个运单要周转几次,现在的中转状态,所以快递行业是中间件使用的最好的场景,如果互联网金融用了中间件,碰到了分布式事务就很也容易呵呵
Ⅳ、理解分库和分表呢
shard是一个标准的说法,但是分库分表根本没有完整的定义,很模糊
最早的时候：
分表：orders ---> orders00,orders01,,,,
分库：db1,db2中都有orders00,orders01,当然也可以分到其他实例中的db中
这样表名改了,不好维护,网易的中间件就不支持分表,那就只分库吧,最好是同一个实例上建很多个不同的db,扩展起来不用打散数据
所以这里又有个淘宝的规范,一开始可能就会分1024个shard,不管多少个机器,一开始放在100个机器上,双十一放到1000个机器上,具体落到哪个shard还是用hash
不能2048个shard,MySQL数据库扩展是不做reshard的,重分布的代价太大,所以就拆,在一开始在同一个机器上做很多个shard
一开始就把shard就划好,扩展的时候不用每次都去打散数据,换句话说,这样做的是垂直扩展,虽然说分布式数据库可扩展,但是因为hash的扩展很麻烦,涉及到数据的重分布,所以尽量垂直扩展,数据打散水平打散,扩展的话垂直扩展
mongodb的扩展方便,是基于chunck的,先把所有的数据放到chunck里,如果超过32M会做split,拆成两个chunck,然后做一个balance的操作,把两个chunck放到两台服务器上,所以这个chunck是可以移动的,mysql的hash不可移动
mongodb的balance也有问题,牵涉到一台服务器的chunck拷贝到另一台服务器
各有优缺点,扩展方便,新加一台机器,可以把各个机器上的chunck移过来,不用hash那样整个集群的重分布,只拿一部分chunck过来,但是io会很大
|
