宁夏网站建设哪家好,顺义哪有做网站厂家,wordpress 后台修改,网站建设择在很多业务里#xff0c;分库分表键都是根据主要查询筛选出来的#xff0c;那么不怎么重要的查询怎么解决呢#xff1f; 比如电商场景下#xff0c;订单都是按照买家ID来分库分表的#xff0c;那么商家该怎么查找订单呢#xff1f;或是买家找客服#xff0c;客服要找到对…在很多业务里分库分表键都是根据主要查询筛选出来的那么不怎么重要的查询怎么解决呢 比如电商场景下订单都是按照买家ID来分库分表的那么商家该怎么查找订单呢或是买家找客服客服要找到对应的订单又该怎么找
分库分表键的选择
选择进行分库分表的业务字段有的时候会有多个字段如何选择合适的字段呢 关键点就是 根据查询来选择 。例如在订单里面最常见的是按照买家来进行分库分表理由是买家查询自己的订单是最主要的场景这样收益最大。这个完全是业务驱动的最常用的分库分表键有主键、外键、索引列如果是范围分库分表那么日期类型的列也很常用。
重试方案
设置一个重试方案要考虑3个方面的内容
重试次数无限次重试意义并不大重试间隔等间隔重试或指数退避重试。后者指的是重试间隔的时间在增长一般是两倍增长面试的时候可以设计一些更加灵活的重试比如最开始按照两倍增长再按照50%增长最后保持最大重试间隔不断重试是否允许跨进程重试在进程A里触发了重试但是重试一次后是否可以在进程B上重试第二次对应到分布式环境上意味着是否可以在不同的机器上重试。 理论上说重试是为了避开前一次失败的原因比如因为偶发的网络抖动失败。设计指数退避的重试策略的原因也很简单通过不断延长重试时间间隔有更大的概率避开引发失败的因素。
面试准备
分库分表的主键生成策略如果使用了后续提到的引入中间表、二次分库分表和使用其他中间件支持查询中的任何一个方案就需要搞清楚数据同步的方案换句话说如果数据不一致多久会发现最终要多久才能达成一致。
简历里或面试里提到分库分表方案设计的时候主动提起是如何解决这个问题的 面试常见问题引导
问到了主键生成策略那么你可以说主键生成会影响分库分表的中间表设计。面试官问到了从其他维度怎么查询数据的问题。例如在订单这里问到了客服怎么查、运营怎么查等。面试官问到了数据同步和数据一致性你可以用这里面谈到的场景来展示你是如何解决这些问题的。面试官问到了如何选择合适的分库分表键那么你就可以强调非分库分表键的查询更加复杂需要额外的支持。
基本思路
面试官都是直接问类似的问题比如介绍了分库分表方案后提到订单表是按照买家ID来进行分库分表的之后会顺势问如果卖家要查询ID应该怎么办 可以按照这个模板来介绍不同的方案 这一类没有按照分库分表键来筛选数据的查询是需要一些额外的手段来支持的。目前来说主流的方案是引入中间表、二次分库分表或是使用其他中间件。当然广播作为一个兜底的解决方案逼不得已的时候也可以使用。当然如果自己的主键生成策略比较特殊的话也能部分支持这一类查询。 接下来按照这些关键词一个一个地问
主键生成策略
有一种主键生成的策略是在主键里面带上分库分表的列如果能够拿到主键就应该知道去哪个数据库上的哪个数据表里查找。 比如在订单ID里带上了买家ID那么在根据订单ID来查询数据的时候就可以通过订单ID来判断订单的数据在哪个库哪个表里。 这是一种很优雅的解决方案**既不需要任何第三方工具的帮助也不需要额外存储数据**。但是这个方案只能解决一部分问题而且大多数时候主键都不是采用这种策略生成的只能考虑其他方案了比如引入中间表。
引入中间表
如果想支持按照卖家来搜索可以引入一个中间表记录了ID、卖家ID和买家ID三个数据。 当然也可以考虑把买家ID换成目标库和目标表这样就省去了根据买家ID来定位目标库和目标表的步骤。 查询的基本步骤也很清晰
先在中间表里根据卖家ID找到想要的订单ID和买家ID再根据买家ID和订单号找到具体的订单数据
关键词就是中间表 我们用了一个比较简单的方案引入中间表来解决卖家查询的问题。中间表主要是根据卖家找到对应的订单并且根据订单表中的买家ID来确定目标库、目标表再去对应的数据表里把所有的数据都查询出来。 这个基本方案可以从两个角度刷亮点 第一个角度是结合主键生成策略优化中间表的设计 在设计订单主键的时候将买家ID编码放到了订单ID里中间表里就可以考虑删除买家ID列。 第二个角度是讨论中间表的缺陷最大的缺陷是性能瓶颈 这个方案的一个重大缺陷是中间表的性能瓶颈。如果中间表的数据只插入不存在更新的话主要是读瓶颈那么多加几个从库就可以解决但是如果中间表的一些列是需要频繁被更新的那么中间表本身就扛不住写压力但是中间表是不能分库分表的因为分库分表后不知道该查询哪张中间表。 中间表最让人害怕的就是写瓶颈可以考虑提供一个解决方案 一般来说在设计中间表的时候就应该包含尽可能少的列而且这些列的值应该尽可能不变会频繁更新的列就不要放了。比如 订单ID这种ID列的基本不会变状态这种经常变更的就不要放了。 中间表还有两个明显的缺陷难以适应灵活多变的查询场景还有数据一致性问题。 中间表还有一个缺陷就是表结构很固定如果将来需要支持新的查询场景必须要修改中间表的表结构大多数情况下会增加新的列。另一方面中间表本身往往是一个大表大表改表结构是一个非常危险的事情当然也可以考虑增加新的中间表但是治标不治本而且中间表越多越难维护数据一致性越难保证。 进一步思考中间表要想解决写瓶颈是不是也可以分库分表
二次分库分表
二次分库分表指复制出来一份数据然后尝试再进行分库分表。所以你的系统里会有两份数据分别按照不同的分库分表规则来存储。比如卖家需要查询订单那么可以再一次按照卖家ID来进行分库分表。 原本订单表是按照买家ID来进行分库分表的但是这种情况下卖家查询订单很困难。比如卖家查询自己当日成交的订单量就难以支持。而且卖家查询订单也不能算是一个低频行为所以尝试把数据复制了一份出去然后按照卖家ID分库分表。这种方案的主要缺陷就是数据一致性问题以及数据复制一份需要很多的存储空间。 数据复制一份的问题解决起来也很简单只需要复制关键表以及关键表的关键字段就可以了。部分表是不需要复制的比如订单详情表完全不需要复制在拿到订单ID之后再次查询订单详情表 即使复制表也不是所有的字段都需要复制一些BLOB、TEXT字段占用存储空间多还不会出现在查询条件里根本不需要复制。如果真的需要这些字段可以拿主键和分库分表键二次查询。 这里的查询也分为了两部但是要尽量做到大部分查询只查卖家库只有少部分查询需要回归到买家库。 关键词是减轻存储压力 实际上为了减轻数据复制带来的存储压力我们可以考虑只复制一部分表或者某个表的一部分字段。比如在同步的时候就不需要同步订单详情表而是拿到订单基本信息之后再去原本的买家库里面查询订单详情。 在这里可以进一步讨论两次查询引入的问题以及可行的优化方案 在这种机制之下如果有一个查询QPS比较高但是又经常需要回原表查询可以考虑两个优化方案首先是在查询的SELECT部分去除一些用不上的列避免回原表如果这个措施不可以就考虑把查询所需的列全部复制过去避免回原表。第二种优化类似平时用覆盖索引来优化查询。 使用其他中间件
为了支持复杂多样的查询可以尝试使用别的中间件比如Elasticsearch。在引入Elasticsearch的时候也可以采用引入中间件方案中的一个优化措施即只同步部分和搜索相关的字段。 为了减轻 Elasticsearch 的压力我们选择了只同步部分字段。一些非常庞大的字段比如说 TEXT 或者 BLOB 本身我们是不会同步过去的。 如果你选了同步部分数据到 Elasticsearch那么你最终就会面临一个问题总有一些业务的查询你完全没办法支持。那这个时候你就只剩下最后一个手段了广播。
广播
如果不能断定数据可能出现在哪一张表上那么就直接把全部表上都查询一遍。 当卖家想要知道自己究竟卖了多少单的时候就可以在所有的表上都问一遍汇总之后就是卖家的所有订单
这种做法的缺陷对数据库的压力太大。只有兜底的时候才使用。 我们还有一些兜底措施也就是如果一个查询确实没办法使用前面那些方案的时候那就可以考虑使用广播。也就是说直接把所有的请求发送到所有的候选节点里面然后收集到的数据就是查询的结果。不过这种方式的缺陷就是对数据库压力很大很多数据库上的表根本不可能有数据但是都会收到请求白白浪费资源。尤其是如果这些查询还会触发锁那么性能就会更差。 引入中间表和二次分库分表
实际上可以理解为二次分库分表是中间表的升级加强版
中间表是性能瓶颈害怕维护写频繁的字段二次分库分表没有这种担忧中间表本身的字段会很少往往需要回归原表再次查询数据二次分库分表成本要更高因为需要复制更多的字段
一般来说优先考虑使用中间表其次考虑只复制部分数据的二次分库分表方案逼得不得已再考虑全量复制数据的二次分库分表方案
数据同步问题
引入中间表、二次分库分表和使用其他中间件三个解决方案里都面临同样一个问题如何进行数据同步 一般有两种数据同步的思路
双写在写入源数据表的时候同时写到另一个地方。可以通过改造ORM或分库分表中间件达成。 利用 Canal 之类的框架监听 binlog然后异步地把数据库同步到其他地方。 不管是双写还是监控 binlog都绕不开失败这个话题。那失败的时候怎么办呢**无非就是各种重试在重试都失败之后就人手工介入处理。**在实践中双写方案用得不多。高端一点的做法就是在重试失败之后加上一个异步修复程序进一步尝试修复。如果修复程序本身也失败了那确确实实就只能人手工介入了。这些内容之前我反复提到过你需要记住。
亮点方案 在分库分表之后为了充分满足不同情况下的查询需求我们公司综合使用了三种方案引入中间表、二次分库分表和 Elasticsearch。对于卖家查询来说我们直接复制了一份数据按照卖家 ID 分库分表。对于一些复杂的查询来说就是利用 Elasticsearch。还有一些查询是通过建立中间表来满足比如说商品 ID 和订单 ID 的映射关系。
数据同步方案是使用监听 binlog 的方案。买家库插入数据之后就会同步一份到卖家库和 Elasticsearch 上。这个过程是有可能失败的那么在失败之后会有重试机制如果重试都失败了那么就只能人手工介入处理了。
这个架构里的另一个问题是卖家库的数据需要反向同步到买家库吗 第一个回答是如果允许卖家修改卖家库的数据就需要反向同步架构变成了下图。 我们是允许卖家直接修改数据的所以实际上我们卖家库的修改也会同步到其他数据源。因为卖家和买家都可能同时修改各自的库。这里我举一个订单状态修改的例子。 如果买家发起取消订单然后卖家那边要把状态修改成已发货。那么可能出现买家先修改然后被卖家覆盖的情况结果就是两边都是已发货也有可能出现卖家先修改然后被买家覆盖的情况那么结果就是两边都是已取消。 所以类似的场景最好是采用分布式锁和双写方案。比如买家修改状态的时候要先拿到分布式锁然后同时修改买家库和卖家库。当然要是覆盖数据也没关系那么就还是可以继续采用 Canal 的同步方案。 所以综合来看允许卖家直接修改卖家库是比较危险的事情数据一致性问题更加严重。 这里提到了数据一致性问题更加严重这也是为了引出第二个回答就是除了买家库其他库都是只读的。 也可以考虑只允许从买家库进去修改数据也就是说不允许直接修改卖家库的数据。 举个例子如果卖家想要修改某个订单的数据那么他需要在卖家库查到订单的信息但是在修改的时候要拿着订单信息去买家库修改。 这种做法最大的优点就是简单没有那么多数据同步和数据一致性方面的问题。缺点就是性能比较差而且写压力始终都在买家库上。
