AI/计算机志愿填报指南发布！

这个方法的优点是：

• 一个用户发布的所以帖子落在同一个库上;
• 10%的请求过过uid来查询列表，可以直接定位到库;
• 索引表cache命中率非常高，因为tid与uid的映射关系不会变;

缺点也很明显：

• 90%的tid请求，以及100%的修改请求，不能直接定位到库，需要先进行一次索引表的查询，当然这个查询非常块，通常在5ms内可以返回;
• 数据插入时需要操作元数据与索引表，可能引发潜在的一致性问题;

有没有一种方法，既能够通过uid定位到库，又不需要建立索引表来进行二次查询呢，使得uid和tid都能够直接一次命中的方案呢?

方案三：基因法

(1) 什么是分库基因?

通过uid分库，假设分为16个库，采用uid%16的方式来进行数据库路由，这里的uid%16，其本质是uid的最后4个bit决定这行数据落在哪个库上，这4个bit，就是分库基因。

(2) 什么是基因法分库?

在“1对多”的业务场景，使用“1”分库，在“多”的数据id生成时，id末端加入分库基因，就能同时满足“1”和“多”的分库查询需求。


 

• 这个库只有两列，可以承载很多数据;
• 即使数据量过大，索引库可以利用tid水平切分;
• 这类kv形式的索引结构，可以很好的利用cache优化查询性能;
• 一旦帖子发布，tid和uid的映射关系就不会发生变化，cache的命中率会非常高;

使用uid分库，并增加索引库记录tid到uid的映射关系之后，每当有uid上的查询，可以通过uid直接定位到库。

 

如上图，一个uid访问需要遍历所有库。

有没有一种切分方法，确保同一个用户发布的所有帖子都落在同一个库上，而在查询一个用户发布的所有帖子时，不需要去遍历所有的库呢?

方案二：用户ID切分法

使用uid来分库可以解决这个问题。

新的问题出现了：如果使用uid来分库，确保了一个用户的帖子数据落在同一个库上，那通过tid来查询，就不知道这个帖子落在哪个库上了，岂不是还需要遍历全库，需要怎么优化呢?

tid的查询是单行记录查询，只要在数据库(或者缓存)记录tid到uid的映射关系，就能解决这个问题。

新增一个索引库：

（编辑：通化站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!