架构第六周 - 学习总结

发布于: 2020 年 07 月 12 日

单表数据量太大时,如何改造才能保证数据的高性能存储?

数据分片,将一张表的数据拆分中若干份存储在多台服务器上,降低单节点的压力。实现方式:

① 硬编码实现数据分片,比如ID奇偶数分别存在在两台服务器上。

②查找映射表,比如用映射表,数据存储在多台服务器如<userID,ServerNo>建立映射表,但是这种方式实践中不多见,一是因为映射表查找这一步是多出来的,第二是建立大数据量映射表本身不简单。

③分布式数据库中间件,比如Mycat。原理是解析模块来解析SQL拿到分片字段,由路由模块进行查找服务器DB,执行SQL。有可能解析SQL得到的是多个分片字段,路由到多个DB,那么最后也会得到多个结果集,所以也有一个结果集合并模块,这就是cobar组件的模型。路由模块是怎么做的呢?其实是根据事先配置好的路由规则去判断的,这个路由规则比较重要,比如余数Hash会影响集群的伸缩,那怎么办?办法就是一个Mysql实例中的多个schema比如0~3共4个,那么3个Mysql实例也就是12个scheam,新增Mysql实例扩容时,将原来每个Mysql实例中的某个schema拿出来放在新的Mysql实例上,这就是扩容过程mysql的数据移动过程,可以看出来还是余数hash,算法没变,hash(key)%12,结果也不变。需要注意的是分片之后数据库查找基本告别join了,只能单表依次查询。

CAP原理

①P分区耐受性,必然存在,所以一般是做A与C的取舍。

②即便是取舍,A和C也许最后一个都得不到。

③完全高可用的系统不存在,完全一致性的系统也不存在,即使有代价非常之大。

④最终一致性用的最多,但是最终一致的时间不能太久,不然没有意义。

⑤最终一致性的解决策略:

1 根据时间戳进行写覆盖。

2 业务选择,由客户在客户端进行冲突破解,虽然服务端存储的是不一致数据。

3 投票解决冲突,如Cassandra数据库,利用鸽臼原理。

架构师思维

  • 一个企业中有价值的任务有限,有限的有价值的东西可以认为是机会,而机会必须要凭自己去争取,要在小组中甚至部门中脱颖而出,才可以得到这样的机会。show yourself!

  • 要想让企业支持你造轮子,那么要拿出:设计目标---逻辑架构---关键技术---项目计划(money/person)

  • 作为架构师要习惯被质疑,应该感到高兴,质疑你的人影响力越大那么你的关注度越大。

  • 架构师不应跟业务团队一起加班,要先于业务团队考虑出问题。

  • 搞清楚问题是什么比解决问题的手段更重要。

发布于: 2020 年 07 月 12 日 阅读数: 4
用户头像

Jeff.Smile

关注

努力支撑经历,经历支撑能力! 2018.12.03 加入

追不上BAT的人... 分享,聚焦

评论

发布
暂无评论
架构第六周 - 学习总结