乐视
他们的全局ID生成采用Snowflake,并且附加了分库分表信息.
也就是说,根据全局ID,就可以知道该信息具体存在哪个数据库中.
比如 userid mod 8 然后拼接在 Snow ID之前
这样通过 GID的前几位,就可以知道分库信息.
但是一旦数据库扩容,ID就会很麻烦.
所以他们 一般mod很大的数字
比如 userid mod 128 拼接 Snow ID
另外,他们最终一致性,将分库的信息,汇总到一个总库,然后对比.
感觉有点繁琐.
最后,乐视的架构师说分库不能无限扩展,
因为每个中间件都需要连接所有的分库.
这样随着中间件,数据库的增多.
每个中间件获得的每个数据库的连接会越少.因为每个数据库的最大连接数量都是有上限的.
所以一般采用微服务拆分,由上层服务决定,分配到哪个微服务处理.
而微服务,只是连接自己的那个数据库就可以了.
58沈剑
最终一致性三种写入方式
1.同步写,写完A库,写B库
缺点
写B库失败,A库如何处理?
假如写A库,B库,最后在提交A库,B库.
则连接和锁的占用时间,都增大了
2.同步写一个库,异步写另外一个库..(这个..看着眼熟)
3.同步写A库,离线异步写B库.(通过Canel抽)
事务补偿三种方式
1.全量扫数据对比
2.扫描增量日志(就是扫描translog和msglog)
3.实时比对
每次写A库或者写B库,都发送一个消息到消息队列,然后由一个消费者程序,同时收到两个消息,则认为事务完成.否则超时事务补偿.
但是这个消息队列的可靠性由什么保证呢.也是一个麻烦的事情.
他们的全局ID生成采用Snowflake,并且附加了分库分表信息.
也就是说,根据全局ID,就可以知道该信息具体存在哪个数据库中.
比如 userid mod 8 然后拼接在 Snow ID之前
这样通过 GID的前几位,就可以知道分库信息.
但是一旦数据库扩容,ID就会很麻烦.
所以他们 一般mod很大的数字
比如 userid mod 128 拼接 Snow ID
另外,他们最终一致性,将分库的信息,汇总到一个总库,然后对比.
感觉有点繁琐.
最后,乐视的架构师说分库不能无限扩展,
因为每个中间件都需要连接所有的分库.
这样随着中间件,数据库的增多.
每个中间件获得的每个数据库的连接会越少.因为每个数据库的最大连接数量都是有上限的.
所以一般采用微服务拆分,由上层服务决定,分配到哪个微服务处理.
而微服务,只是连接自己的那个数据库就可以了.
58沈剑
最终一致性三种写入方式
1.同步写,写完A库,写B库
缺点
写B库失败,A库如何处理?
假如写A库,B库,最后在提交A库,B库.
则连接和锁的占用时间,都增大了
2.同步写一个库,异步写另外一个库..(这个..看着眼熟)
3.同步写A库,离线异步写B库.(通过Canel抽)
事务补偿三种方式
1.全量扫数据对比
2.扫描增量日志(就是扫描translog和msglog)
3.实时比对
每次写A库或者写B库,都发送一个消息到消息队列,然后由一个消费者程序,同时收到两个消息,则认为事务完成.否则超时事务补偿.
但是这个消息队列的可靠性由什么保证呢.也是一个麻烦的事情.
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/29254281/viewspace-2119020/ ，如需转载，请注明出处，否则将追究法律责任。
请登录后发表评论
登录
全部评论
