边缘分布函数,边缘分布函数怎么求

投稿用户 • • 兼职副业 • 阅读 60

背景介绍

业务需求

上篇我们刚解决了客户更新订单的“已发货”状态的数据一致性问题，正准备满足客户新提出来的统计需求。结果天有不测风云，系统出问题了，客户反馈系统订单列表刷不出来。如果对背景不太了解的可以参考我的上篇文章《亿级数据量下的数据强一致方案（分存方案） 》。

问题定位

经过排查，发现查询列表慢并不是因为索引返回的慢，而是反查HBase明细变慢了。按理说不应该呀，这个号称能抗几百万QPS的存储咋就不行了呢？结果我们发现访问某个HBase节点的请求特别多，而且每个节点的存储量差距较大，大概如下图所示：

边缘分布函数,边缘分布函数怎么求

原来这就是传说中的分片不均（Sharding Imbalance）。导致分片不均的原因是作为行键（Row Key）的订单ID不均衡导致的。我们的订单ID一般为“20221115013456798473”这样的一串带时间和业务标识的字符串。开头为日期，那么一年的订单都会被分配到一个分片（Shard）中，这就导致了数据分片严重失衡。

解决方案

解决思路

我们不可能改变订单的ID，所以只能通过变换存储时的Row Key来实现数据的均衡。这里我们可以通过将订单ID进行哈希计算（Hashing，也叫散列计算），生成一个随机的字符串（如425f0d5a917188d2c3c3dc85b5e4f2cb）来存储，这样就可以解决分片不均的问题了。但是我们又引入了另外一个问题，那就是哈希碰撞问题，即不同的两个订单ID可能哈希成一个哈希值，导致相互覆盖的问题。那如果我们取哈希值的后四位加上订单号进行存储（f2cb20221115013456798473），这不就完美解决了么，不愧是共和国最优秀的程序员，为自己鼓掌。

这里细心的小伙伴可能会提出疑问，那我怎么通过订单ID去查数据呢？答案也很简单，就是每次查询时进行上述Row Key的生成进行查询即可。因为哈希算法是稳定的，每次都能生成固定的后四位Row Key前缀。

问题回归

果然程序员的日子不好过，刚想着手解决客户的统计需求就跑出来这么个问题，还好双十一没出事，不然就大件事了。但是大几百万的数据要做实时统计，查询还得保持在500毫秒之内返回，这个需求确实有点挑战，我得好好想想。

创业项目群，学习操作 18个小项目，添加 微信：790838556  备注：小项目！

本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 zoodoho@qq.com举报，一经查实，本站将立刻删除。
如若转载，请注明出处：https://www.zoodoho.com/47038.html
赞 (0)
投稿用户
0
上一篇 2022年11月21日 pm9:07
下一篇 2022年11月21日 pm10:27

相关推荐