Java学习者

作者：微信小助手

<section style="line-height: 1.75em;"> 开篇 </section> <section style="line-height: 1.75em;"> 同一个用户并发扣款时，有一定概率出现数据不一致，可以使用CAS乐观锁的方式，在不降低吞吐量，保证数据的一致性： </section> UPDATE t_yue SET money=$new_money WHERE uid=$uid AND money=$old_money; <section style="line-height: 1.75em;"> 更详细的描述，详见《<a href="http://mp.weixin.qq.com/s?__biz=MjM5ODYxMDA5OQ==&mid=2651962738&idx=1&sn=d2d91a380bad06af9f7b9f7a80db26b3&chksm=bd2d08ae8a5a81b8a7f044af52c5e6e77ec3df2bb4a9c91cd450c3fd932e8dade56afb09f784&scene=21#wechat_redirect" target="_blank" data-itemshowtype="0" data-linktype="2">并发扣款，如何保证数据的一致性？</a>》。 </section> <section style="line-height: 1.75em;">   </section> <section style="line-height: 1.75em;"> 不能采用直接扣减的方式 ： </section> UPDATE t_yue SET money=money-$diff WHERE uid=$uid; <section style="line-height: 1.75em;"> 更详细的描述，详见《<a href="http://mp.weixin.qq.com/s?__biz=MjM5ODYxMDA5OQ==&mid=2651962770&idx=1&sn=94efc914b0e7d6a74948926a3ea7e9c6&chksm=bd2d084e8a5a8158e7e73d3b917e5189127087a45d78b81ce96db48e6ae2e89cd0bd11c8f301&scene=21#wechat_redirect" target="_blank" data-itemshowtype="0" data-linktype="2">并发扣款一致性，幂等性问题</a>》。 </section> <section style="line-height: 1.75em;">   </section> <section style="line-height: 1.75em;"> 当然，更通用的方式，可以使用版本号来实现CAS乐观锁： </section> UPDATE t_yue SET money=$new_money,ver=$ver_new WHERE uid=$uid AND ver=$ver_old; <section style="line-height: 1.75em;"> 更详细的描述，详见《<a href="http://mp.weixin.qq.com/s?__biz=MjM5ODYxMDA5OQ==&mid=2651962761&idx=1&sn=11513a9e34bf77b4545ecdc289f4c8fd&chksm=bd2d08558a5a8143ce15fbd9722fbcc42593b55480ca5eba7b19b2911763bb15bde65e9a2c4b&scene=21#wechat_redirect" target="_blank" data-itemshowtype="0" data-linktype="2">并发扣款一致性优化，CAS下ABA问题</a>》。 </section> <section style="line-height: 1.75em;">   </section> <section style="line-height: 1.75em;"> 对于这个CAS乐观锁方案，很有朋友有疑问： 当并发量高时，版本号比对会导致大量的更新失败，这个方案不适用于高并发场景吗？ </section> <section style="line-height: 1.75em;">   </section> <section style="line-height: 1.75em;"> 究竟是不是这样呢？ 大家对高并发是不是有什么误解呢？ 今天来聊一聊这个话题。 先分析三个业务场景。 </section> <section style="line-height: 1.75em;">   </section> <section style="line-height: 1.75em;"> 一、QQ </section> <section style="line-height: 1.75em;"> QQ的一些核心业务有： </section> <ul style="list-style-type: disc;" class=" list-paddingleft-2"> <li>个人：user(uid, user_info, …)</li> <li>好友：user_friends(uid, friend_id, …)</li> <li>加入的群：user_groups(uid, group_id, …)</li> <li>群：group(gid, group_info, …)</li> <li>群成员：group_members(gid, uid, …)</li> <li>个人消息：msgs_user(msg_id, uid, …)</li> <li>群消息：msgs_group(msg_id, gid, …)</li> </ul> <section style="line-height: 1.75em;"></section> <section style="line-height: 1.75em;"></section> <section style="line-height: 1.75em;"></section> <section style="line-height: 1.75em;"></section> <section style="line-height: 1.75em;"></section> <section style="line-height: 1.75em;"></section> <section style="line-height: 1.75em;"></section> <section style="line-height: 1.75em;">   </section> <section style="line-height: 1.75em;"> 这些信息的读写有一个特点，都会带上uid/gid/msgid属性。 </section> <section style="line-height: 1.75em;">   </section> <section style="line-height: 1.75em;"> 例如，拉取好友列表： </section> select friend_id from user_friends where uid=$uid; <section style="line-height: 1.75em;">   </section> <section style="line-height: 1.75em;"> 在用户量很大，并发量很大时， 不同用户/群/消息数据的读写并没有锁冲突 。 </section> <section style="line-height: 1.75em;"> 画外音：10W个用户同时读写，彼此没有锁冲突。 </section> <section style="line-height: 1.75em;">   </section> <section style="line-height: 1.75em;"> 只有当，同一个用户，很短的时间内，有大量并发时，才可能存在锁冲突。 </section> <section style="line-height: 1.75em;"> 画外音：例如，1个用户，1秒钟读写1W次。 </section> <section style="line-height: 1.75em;">   </section> <section style="line-height: 1.75em;"> 二、微博 </section> <section style="line-height: 1.75em;"> 微博的核心业务是feed流： </section> <ul style="list-style-type: disc;" class=" list-paddingleft-2"> <li>发消息，写操作</li> <li>刷消息，读操作</li> </ul> <section style="line-height: 1.75em;"></section> <section style="line-height: 1.75em;"></section> <section style="line-height: 1.75em;">   </section> <section style="line-height: 1.75em;"> 微博业务显然是 读多写少 的，在用户刷消息时， 自己feed流里的消息，是由别人发出的 。 </section> <section style="line-height: 1.75em;">   </section> <section style="line-height: 1.75em;"> 查看自己主页feed流 ，最朴素的实现方法是： </section> <section style="line-height: 1.75em;"> (1) 拉取自己关注的用户id_list； </section> <section style="line-height: 1.75em;"> (2) 拉取这些用户最近N条消息； </section> <section style="line-height: 1.75em;"> (3) 将这N*id_list条消息排序； </section> <section style="line-height: 1.75em;"> (4) 返回第一页消息，得到自己主页feed流； </section> <section style="line-height: 1.75em;"> 画外音：这里不展开读扩散，写扩散，详见《<a href="http://mp.weixin.qq.com/s?__biz=MjM5ODYxMDA5OQ==&mid=2651961939&idx=1&sn=31a0a4b45a25befbde5b05fe0ba574f6&chksm=bd2d0f8f8a5a86994f983eb45873e06145d5ebbafedec9adf039aabef9cef70700b87e0c5aa8&scene=21#wechat_redirect" target="_blank" data-itemshowtype="0" data-linktype="2">读扩散？写扩散？</a>》。 </section> <section style="line-height: 1.75em;">   </section> <section style="line-height: 1.75em;"> 在用户量很大，并发量很大时， 会有一定数据的读写锁冲突 。 </section> <section style="line-height: 1.75em;"> 画外音：不像QQ，基本是读写自己的数据，微博要写自己的数据，读别人的数据。 </section> <section style="line-height: 1.75em;">   </section> <section style="line-height: 1.75em;"> 三、12306 </section> <section style="line-height: 1.75em;"> 12306的核心业务是： </section> <ul style="list-style-type: disc;" class=" list-paddingleft-2"> <li>查票，读操作</li> <li>买票，写操作</li> </ul> <section style="line-height: 1.75em;"></section> <section style="line-height: 1.75em;"></section> <section style="line-height: 1.75em;">   </section> stock(id, num) // 某一列车有多少张余票 <section style="line-height: 1.75em;">   </section> <section style="line-height: 1.75em;"> 在用户量很大，并发量很大时， 有极大的锁冲突 。 </section> <section style="line-height: 1.75em;"> 画外音：这个业务，数据量并不大。 </section> <section style="line-height: 1.75em;">   </section> <section style="line-height: 1.75em;"> 这类“秒杀”业务，如果不做特殊的优化， 数据库很容易死锁卡死 ，没有任何人能买票成功。 </section> <section style="line-height: 1.75em;"> 画外音：要做什么特殊的优化呢？ </section> <section style="line-height: 1.75em;">   </section> <section style="line-height: 1.75em;"> 收尾 </section> <section style="line-height: 1.75em;"> QQ，微博、12306，同样是高并发业务，就数据存储锁冲突来说，各自的难度，数据不一致的概率是不同的。 </section> <section style="line-height: 1.75em;"> 画外音：你不能说，QQ不是高并发业务吧。 </section> <section style="line-height: 1.75em;">   </section> <section style="line-height: 1.75em;"> 回到开篇，使用CAS乐观锁进库存扣减： </section> UPDATE t_yue SET money=$new_money,ver=$ver_new WHERE uid=$uid AND ver=$ver_old; <section style="line-height: 1.75em;"> 只要有uid这个过滤属性，即使10W用户同时扣款，也不容易出现数据不一致 。 </section> <section style="line-height: 1.75em;">   </section> <section style="line-height: 1.75em;"> 只有当同一个用户，同一秒钟，有大量扣减时，才有一定几率会冲撞，但也不会导致数据不一致。 </section> <section style="line-height: 1.75em;"> 画外音：有一位很可爱的水友，说万一PC端和APP端同时下单怎么办。 </section> <section style="line-height: 1.75em;">   </section> <section style="line-height: 1.75em;"> 结论 高并发的扣款场景，可以使用CAS乐观锁，采用select&set方式进行扣款，既能够保证吞吐量，又能够保证一致性。 </section> <section style="text-align: center;color: rgb(51, 51, 51);line-height: normal;clear: both;box-sizing: border-box;background-color: rgb(255, 255, 255);"> <strong style="box-sizing: border-box;margin-bottom: 0px;margin-left: 0px;margin-right: 0px;margin-top: 0px;max-width: 100%;padding-bottom: 0px;padding-left: 0px;padding-right: 0px;padding-top: 0px;word-wrap: break-word;"><img style="box-sizing: border-box;margin: 0px;max-width: 677px;padding: 0px;visibility: visible !important;overflow-wrap: break-word;width: 130px !important;height: auto !important;" data-ratio="1" data-type="jpeg" data-w="250" data-s="300,640" class="" src="/upload/7ddc9700032e2c5cee163f1f1a37b46c.jpg" width="auto"> </section> <section style="text-align: center;color: rgb(51, 51, 51);line-height: normal;clear: both;box-sizing: border-box;background-color: rgb(255, 255, 255);"> <strong style="box-sizing: border-box;margin-bottom: 0px;margin-left: 0px;margin-right: 0px;margin-top: 0px;max-width: 100%;padding-bottom: 0px;padding-left: 0px;padding-right: 0px;padding-top: 0px;word-wrap: break-word;"><strong style="box-sizing: border-box;margin-bottom: 0px;margin-left: 0px;margin-right: 0px;margin-top: 0px;max-width: 100%;padding-bottom: 0px;padding-left: 0px;padding-right: 0px;padding-top: 0px;word-wrap: break-word;">架构师之路-分享技术思路<strong style="box-sizing: border-box;margin-bottom: 0px;margin-left: 0px;margin-right: 0px;margin-top: 0px;max-width: 100%;padding-bottom: 0px;padding-left: 0px;padding-right: 0px;padding-top: 0px;word-wrap: break-word;"><br style="box-sizing: border-box;margin-bottom: 0px;margin-left: 0px;margin-right: 0px;margin-top: 0px;max-width: 100%;padding-bottom: 0px;padding-left: 0px;padding-right: 0px;padding-top: 0px;word-wrap: break-word;"> </section> <section style="margin: 0px;padding: 0px;text-align: left;color: rgb(51, 51, 51);text-transform: none;line-height: 1.75em;text-indent: 0px;letter-spacing: 0.54px;clear: both;font-size: 17px;font-style: normal;font-variant: normal;font-weight: 400;text-decoration: none;word-spacing: 0px;white-space: normal;word-wrap: break-word;min-height: 17px;max-width: 677px;box-sizing: border-box;orphans: 2;-webkit-text-stroke-width: 0px;background-color: rgb(255, 255, 255);"> 相关文章： </section> <section style="margin: 0px;padding: 0px;text-align: left;color: rgb(51, 51, 51);text-transform: none;line-height: 1.75em;text-indent: 0px;letter-spacing: 0.54px;clear: both;font-size: 17px;font-style: normal;font-variant: normal;font-weight: 400;text-decoration: none;word-spacing: 0px;white-space: normal;word-wrap: break-word;min-height: 17px;max-width: 677px;box-sizing: border-box;orphans: 2;-webkit-text-stroke-width: 0px;background-color: rgb(255, 255, 255);"> 《<a href="http://mp.weixin.qq.com/s?__biz=MjM5ODYxMDA5OQ==&mid=2651962738&idx=1&sn=d2d91a380bad06af9f7b9f7a80db26b3&chksm=bd2d08ae8a5a81b8a7f044af52c5e6e77ec3df2bb4a9c91cd450c3fd932e8dade56afb09f784&scene=21#wechat_redirect" target="_blank" data-linktype="2" data-itemshowtype="0">并发扣款，如何保证数据的一致性？</a>》 《<a href="http://mp.weixin.qq.com/s?__biz=MjM5ODYxMDA5OQ==&mid=2651962761&idx=1&sn=11513a9e34bf77b4545ecdc289f4c8fd&chksm=bd2d08558a5a8143ce15fbd9722fbcc42593b55480ca5eba7b19b2911763bb15bde65e9a2c4b&scene=21#wechat_redirect" target="_blank" data-itemshowtype="0" data-linktype="2">并发扣款一致性优化，CAS下ABA问题</a>》 《<a href="http://mp.weixin.qq.com/s?__biz=MjM5ODYxMDA5OQ==&mid=2651962770&idx=1&sn=94efc914b0e7d6a74948926a3ea7e9c6&chksm=bd2d084e8a5a8158e7e73d3b917e5189127087a45d78b81ce96db48e6ae2e89cd0bd11c8f301&scene=21#wechat_redirect" target="_blank" data-itemshowtype="0" data-linktype="2">并发扣款一致性，幂等性问题</a>》 《<a href="http://mp.weixin.qq.com/s?__biz=MjM5ODYxMDA5OQ==&mid=2651961939&idx=1&sn=31a0a4b45a25befbde5b05fe0ba574f6&chksm=bd2d0f8f8a5a86994f983eb45873e06145d5ebbafedec9adf039aabef9cef70700b87e0c5aa8&scene=21#wechat_redirect" target="_blank" data-itemshowtype="0" data-linktype="2">读扩散？写扩散？</a>》 </section> <span style="text-align: justify;color: rgb(51, 51, 51);text-transform: none;text-indent: 0px;letter-spacing: 1px;font-family: "mp-quote",-apple-system-font,BlinkMacSystemFont,"Helvetica Neue","PingFang SC","Hiragino Sans GB","Microsoft YaHei UI","Microsoft YaHei",Arial,sans-serif;font-size: 15px;font-style: normal;font-variant: normal;font-weight: 400;text-decoration: none;word-spacing: 0px;display: inline !important;orphans: 2;float: none;-webkit-text-stroke-width: 0px;background-color: transparent;"> <span style="text-align: justify;color: rgb(51, 51, 51);text-transform: none;text-indent: 0px;letter-spacing: 1px;font-family: "mp-quote",-apple-system-font,BlinkMacSystemFont,"Helvetica Neue","PingFang SC","Hiragino Sans GB","Microsoft YaHei UI","Microsoft YaHei",Arial,sans-serif;font-size: 15px;font-style: normal;font-variant: normal;font-weight: 400;text-decoration: none;word-spacing: 0px;display: inline !important;orphans: 2;float: none;-webkit-text-stroke-width: 0px;background-color: transparent;">任何脱离业务的架构设计，都是耍流氓<span style="text-align: justify;color: rgb(51, 51, 51);text-transform: none;text-indent: 0px;letter-spacing: 1px;font-family: "mp-quote",-apple-system-font,BlinkMacSystemFont,"Helvetica Neue","PingFang SC","Hiragino Sans GB","Microsoft YaHei UI","Microsoft YaHei",Arial,sans-serif;font-size: 15px;font-style: normal;font-variant: normal;font-weight: 400;text-decoration: none;word-spacing: 0px;display: inline !important;orphans: 2;float: none;-webkit-text-stroke-width: 0px;background-color: transparent;">。

一文搞懂面试必备的分布式事物方案

作者：微信小助手

<section powered-by="xiumi.us" style="max-width: 100%;box-sizing: border-box;overflow-wrap: break-word !important;"> <section style="margin-top: 10px;margin-bottom: 10px;max-width: 100%;box-sizing: border-box;transform: translate3d(0px, 0px, 0px);text-align: center;overflow-wrap: break-word !important;"> <section style="max-width: 100%;box-sizing: border-box;display: inline-block;vertical-align: middle;width: 406.188px;overflow-wrap: break-word !important;"> <section powered-by="xiumi.us" style="max-width: 100%;box-sizing: border-box;overflow-wrap: break-word !important;"> <section style="box-sizing: border-box;font-size: 16px;"> <section style="box-sizing: border-box;" powered-by="xiumi.us"> <section style="transform: translate3d(0px, 0px, 0px);-webkit-transform: translate3d(0px, 0px, 0px);-moz-transform: translate3d(0px, 0px, 0px);-o-transform: translate3d(0px, 0px, 0px);text-align: center;margin: 10px 0%;box-sizing: border-box;"> <section style="display: inline-block;vertical-align: middle;width: 60%;box-sizing: border-box;"> <section style="box-sizing: border-box;" powered-by="xiumi.us"> </section> </section> <section style="display: inline-block;vertical-align: middle;width: 12%;border-left: 1px solid rgb(209, 222, 203);border-bottom-left-radius: 0px;border-right: 1px solid rgb(209, 222, 203);border-top-right-radius: 0px;border-top-width: 0px;box-sizing: border-box;"> <section style="box-sizing: border-box;" powered-by="xiumi.us"> <section style="box-sizing: border-box;"> <section style="color: rgb(173, 158, 159);box-sizing: border-box;"> </section> </section> </section> </section> </section> </section> </section> <section style="margin-top: 10px;margin-bottom: 10px;max-width: 100%;box-sizing: border-box;overflow-wrap: break-word !important;"> <span style="font-size: 14px;background-color: rgb(255, 255, 255);letter-spacing: 0.544px;color: rgb(15, 15, 15);font-family: -apple-system-font, BlinkMacSystemFont, "Helvetica Neue", "PingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;">本文转载自公众号:Java极客技术，作者:乔二爷 </section> <section style="margin-top: 10px;margin-bottom: 10px;max-width: 100%;box-sizing: border-box;overflow-wrap: break-word !important;"></section> <section style="margin-top: 10px;margin-bottom: 10px;max-width: 100%;box-sizing: border-box;overflow-wrap: break-word !important;"></section> <section style="margin-top: 10px;margin-bottom: 10px;max-width: 100%;box-sizing: border-box;overflow-wrap: break-word !important;"> <span style="font-size: 14px;background-color: rgb(255, 255, 255);letter-spacing: 0.544px;color: rgb(15, 15, 15);font-family: -apple-system-font, BlinkMacSystemFont, "Helvetica Neue", "PingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;">公众号后台回复“ <span style="font-size: 14px;background-color: rgb(255, 255, 255);letter-spacing: 0.544px;font-family: -apple-system-font, BlinkMacSystemFont, "Helvetica Neue", "PingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;max-width: 100%;box-sizing: border-box;color: rgb(255, 76, 0);overflow-wrap: break-word !important;">面试突击 <span style="font-size: 14px;background-color: rgb(255, 255, 255);letter-spacing: 0.544px;color: rgb(15, 15, 15);font-family: -apple-system-font, BlinkMacSystemFont, "Helvetica Neue", "PingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;">”，获得Java面试突击第三版！ </section> </section> </section> </section> </section> <section powered-by="xiumi.us" style="max-width: 100%;box-sizing: border-box;overflow-wrap: break-word !important;"> <section style="max-width: 100%;box-sizing: border-box;overflow-wrap: break-word !important;"> <section style="max-width: 100%;box-sizing: border-box;font-size: 14px;text-align: center;line-height: 1.8;color: rgb(15, 15, 15);overflow-wrap: break-word !important;"> <hr style="border-style: solid;border-width: 1px 0 0;border-color: rgba(0,0,0,0.1);-webkit-transform-origin: 0 0;-webkit-transform: scale(1, 0.5);transform-origin: 0 0;transform: scale(1, 0.5);"> <span style="font-family: Optima-Regular, Optima, PingFangSC-light, PingFangTC-light, "PingFang SC", Cambria, Cochin, Georgia, Times, "Times New Roman", serif;font-size: 16px;text-align: left;color: rgb(136, 136, 136);">4月初在面试一家互联网公司的过程中就被问到了分布式事物问题。我又一次在没有好好整理的问题上吃了亏。记录一下！！！ <strong style="color: rgb(136, 136, 136);font-family: Optima-Regular, Optima, PingFangSC-light, PingFangTC-light, "PingFang SC", Cambria, Cochin, Georgia, Times, "Times New Roman", serif;font-size: 16px;text-align: left;letter-spacing: 0.544px;"> </section> </section> </section> <p style="box-sizing: border-box;margin: 10px;font-size: 16px;white-space: normal;text-align: center;color: rgb(63, 63, 63);line-height: 1.6;font-family: Optima-Regular, Optima, PingFangSC-light, PingFangTC-light, "PingFang SC", Cambria, Cochin, Georgia, Times, "Times New Roman", serif;">背景 <p style="box-sizing: border-box;margin: 10px;font-size: 16px;white-space: normal;text-align: center;color: rgb(63, 63, 63);line-height: 1.6;font-family: Optima-Regular, Optima, PingFangSC-light, PingFangTC-light, "PingFang SC", Cambria, Cochin, Georgia, Times, "Times New Roman", serif;"> <p style="box-sizing: border-box;margin: 10px;font-size: 16px;white-space: normal;text-align: left;color: rgb(63, 63, 63);line-height: 1.6;font-family: Optima-Regular, Optima, PingFangSC-light, PingFangTC-light, "PingFang SC", Cambria, Cochin, Georgia, Times, "Times New Roman", serif;">四月初，去面试了本市的一家之前在做办公室无人货架的公司，虽然他们现在在面临着转型，但是对于我这种想从传统企业往互联网行业走的孩子来说，还是比较有吸引力的。 <p style="box-sizing: border-box;margin: 10px;font-size: 16px;white-space: normal;text-align: left;color: rgb(63, 63, 63);line-height: 1.6;font-family: Optima-Regular, Optima, PingFangSC-light, PingFangTC-light, "PingFang SC", Cambria, Cochin, Georgia, Times, "Times New Roman", serif;">在面试过程中就提到了分布式事物问题。我又一次在没有好好整理的问题上吃了亏，记录一下，还是长记性！！！ <p style="box-sizing: border-box;margin: 10px;font-size: 16px;white-space: normal;text-align: left;color: rgb(63, 63, 63);line-height: 1.6;font-family: Optima-Regular, Optima, PingFangSC-light, PingFangTC-light, "PingFang SC", Cambria, Cochin, Georgia, Times, "Times New Roman", serif;">先看面试过程 <p style="box-sizing: border-box;margin: 10px;font-size: 16px;white-space: normal;text-align: left;color: rgb(63, 63, 63);line-height: 1.6;font-family: Optima-Regular, Optima, PingFangSC-light, PingFangTC-light, "PingFang SC", Cambria, Cochin, Georgia, Times, "Times New Roman", serif;">面试官先是在纸上先画了这样一张图： <img class="rich_pages" data-copyright="0" data-ratio="0.3650485436893204" data-s="300,640" src="/upload/a865aa7593993a635cb89281f78963dd.png" data-type="png" data-w="1030" style=""> <p style="box-sizing: border-box;margin: 10px;font-size: 16px;white-space: normal;text-align: left;color: rgb(63, 63, 63);line-height: 1.6;font-family: Optima-Regular, Optima, PingFangSC-light, PingFangTC-light, "PingFang SC", Cambria, Cochin, Georgia, Times, "Times New Roman", serif;">让我看这张图按照上面的流程走，有没有什么问题？面试官并没有直接说出来这里面会有分布式事物的问题，而是让我来告诉他，这就是面试套路呀。 <p style="box-sizing: border-box;margin: 10px;font-size: 16px;white-space: normal;text-align: left;color: rgb(63, 63, 63);line-height: 1.6;font-family: Optima-Regular, Optima, PingFangSC-light, PingFangTC-light, "PingFang SC", Cambria, Cochin, Georgia, Times, "Times New Roman", serif;">我回答了这中间可能存在分布式事物的问题，当步骤2在调用 B 系统时，可能存在B 系统处理完成后，在响应的时

Google BigTable到底解决什么问题？

作者：微信小助手

<blockquote> <span style="color: rgb(178, 178, 178);font-family: -apple-system-font, BlinkMacSystemFont, "Helvetica Neue", "PingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 14px;letter-spacing: 1px;text-align: justify;background-color: rgb(255, 255, 255);">搞架构的人，Google的论文是必看的，但好像大家都不愿意去啃英文论文。故把自己的读书笔记，加入自己的思考，分享给大家。 </blockquote> 第三部分，Google BigTable。 BigTable，很多人对它耳熟能详，但它究竟解决什么问题呢？这是今天要聊的话题。   什么是BigTable？ Google BigTable是一个分布式，结构化数据的存储系统，它用来存储海量数据。该系统用来满足“大数据量、高吞吐量、快速响应”等不同应用场景下的存储需求。 画外音：本质上，BigTable是一个存储系统。   有BigTable之前，Google面临什么问题？ Google并不是一群人坐在办公室开会，想出来的系统，Google面临着很实际的业务问题。 画外音： 很多公司的基础架构部，是坐在办公室开会，想出来的东西，然后强推业务线使用； 脱离业务的技术，都是耍流氓。   典型场景一：网页存储   Google每天要抓取很多网页： <ul class=" list-paddingleft-2" style="list-style-type: disc;"> <li>新出现的网页，新URL</li> <li>旧网页，旧URL</li> </ul>   对一个已抓取的网页，旧URL为啥要反复抓取？ 因为，网页会更新，例如新浪首页： sina.com.cn/index.html URL虽然没有变，但依然会抓取。 画外音：我去，相当于，被抓取的URL集合，只会无限增大，趋近无穷，这里面的技术难题，不知道大家感不感兴趣？   这里，对于存储系统的需求，是要存储：不同URL，不同时间Time，的内容Content。 画外音：URL+”Content”+Time => Binary。   网页的实际内容Binary，是Spider抓取出来的。   典型场景二：Google Analytics   Google Analytics要给站长展示其网站的流量PV，独立用户数UV，典型访问路径等，以帮助站长了解站点情况，优化站点。   这里，对于存储系统的需求，是要存储，不同URL，不同时间Time，的PV和UV。 画外音： URL+”PV”+Time => $count URL+”UV”+Time => $count   PV和UV的值，是MapReduce离线任务计算出来的。   不管是“网页存储”还是“站点统计”存储，它们都有几个共同的特点： <ul class=" list-paddingleft-2" style="list-style-type: disc;"> <li>数据量极大，TB，PB级别</li> <li>和时间维度相关</li> <li>同一个主键，属性与值有映射</li> </ul> 画外音： 主键是URL，属性是“Content”，值是网页Binary； 主键是URL，属性是“PV”和“UV”，值是计数count。   这是Google曾经遇到的难题，面对这些难题，典型的解决方案又有哪些呢？ 画外音：不是一上来就搞新方案，最先肯定是想用现有的技术要如何解决。   最容易想到的主键，属性，值的存储系统是什么？ 没错，就是关系型数据库： <img class="" data-copyright="0" data-ratio="0.2814814814814815" data-s="300,640" src="/upload/2b52e8b6b68b5cc519b59709027b4d72.jpg" data-type="jpeg" data-w="405" style=""> 如上图所示，用户表 User(uid PK, name, gender, age, sex) 就是一个典型的主键，属性，值的存储模型： <ul class=" list-paddingleft-2" style="list-style-type: disc;"> <li>主键，不同用户的uid</li> <li>属性，schema的列名</li> <li>值，不同主键的各个列名，对应的值</li> </ul>   使用excel来举例是很直观的，这是一个二维table。 画外音：屎黄色的主键是一个维度，橙色的属性是一个维度。   用二维table能不能解决Google网页存储的问题呢？ <img class="" data-copyright="0" data-ratio="0.2839506172839506" data-s="300,640" src="/upload/e1c43656fae20278f8199df8b4854dc3.jpg" data-type="jpeg" data-w="405" style=""> 如上图所示，如果没有时间维度Time，似乎是可以的： <ul class=" list-paddingleft-2" style="list-style-type: disc;"> <li>主键，使用URL</li> <li>属性，schema的列名，例如content，author等</li> <li>值，不同URL的内容与作者等值</li> </ul>   但是，一旦加入时间维度Time，二维table似乎就不灵了。 画外音： 增加一个time属性是没有用的； 增加一个time属性，只能记录同一个URL，某一个time的content，不能记录多个time的多个content； 增加一个time属性，联合主键，URL就不是KEY了；   能不能用二维table存储三维数据呢？ 似乎可以通过trick的手段，在key上做文章，用key+time来拼接新key来实现。 <img class="" data-copyright="0" data-ratio="0.7160493827160493" data-s="300,640" src="/upload/c6be2a31f8fd3e9c4b12c312fb54fd71.jpg" data-type="jpeg" data-w="405" style=""> 如上图所示，仍然是二维table，通过URL+Time来瓶装key，也能够实现，存储同一个URL，在不同Time，的不同content、author。   但是，这种trick方案存在的问题是： <ul class=" list-paddingleft-2" style="list-style-type: disc;"> <li>没法实现URL查询</li> </ul> 画外音：key上无法进行%like%查询。 <ul class=" list-paddingleft-2" style="list-style-type: disc;"> <li>大量空洞，浪费存储空间</li> </ul> 这并不是一个好的方案。   况且，当数据量达到TB、PB级别时，传统单机关系型数据库，根本无法满足Google的业务需求。   BigTable解决什么问题？ 传统二维small table，无法解决Google面临的存储问题，于是Google搞了一个big table来解决。   Google对这些业务模型进行分析，在二维table的基础上扩充，抽象了一个新的“三维table”： <ul class=" list-paddingleft-2" style="list-style-type: disc;"> <li>主键，使用URL</li> <li>属性，schema的列名，例如content，author等</li> <li>时间，timestamp</li> <li>值，不同URL的内容与作者等值</li> </ul>   <img class="" data-copyright="0" data-ratio="0.6935779816513762" data-s="300,640" src="/upload/6816070ca5062fa062484c5186baacd7.jpg" data-type="jpeg" data-w="545" style=""> 如上图所示： <ul class=" list-paddingleft-2" style="list-style-type: disc;"> <li>第一维：key（屎黄色）</li> <li>第二维：属性（橙色）</li> <li>第三维：time（蓝色）</li> </ul> 同一个key，不同属性，不同时间，会存储一个value。   不像以行为单位进行存储的传统关系型数据库，这个三维的大表格BigTable是一个稀疏列存储系统。 画外音：能够压缩空间。   它的数据模型的本质是一个map： key + column + time => value 的一个超级大map。 画外音： 很多业务符合这一个模型； Google的东西能解决业务问题，所以用的人多，这一点很重要。   总结 BigTable是一个稀疏的、分布式的、持久化的、多维度排序的、大数据量存储系统，它能够解决符合上述map数据模型业务的存储问题。 画外音： GFS是文件系统； MapReduce是计算模型； BigTable是存储系统。   BigTable是啥，解决啥问题，这次终于懂了。   很多时候，定义清楚问题比解决问题更难。 <p style="max-width: 100%;min-height: 1em;color: rgb(51, 51, 51);font-family: -apple-system-font, BlinkMacSystemFont, "Helvetica Neue", "PingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 17px;letter-spacing: 0.544px;white-space: normal;background-color: rgb(255, 255, 255);text-align: center;line-height: normal;box-sizing: border-box !important;word-wrap: break-word !important;"><img width="auto" data-ratio="1" data-w="250" data-type="jpeg" data-s="300,640" class="" src="/upload/7ddc9700032e2c5cee163f1f1a37b46c.jpg" style="max-width: 677px;box-sizing: border-box;word-wrap: break-word;visibility: visible !important;width: 130px !important;"> <p style="max-width: 100%;min-height: 1em;color: rgb(51, 51, 51);font-family: -apple-system-font, BlinkMacSystemFont, "Helvetica Neue", "PingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 17px;letter-spacing: 0.544px;white-space: normal;background-color: rgb(255, 255, 255);text-align: center;line-height: normal;box-sizing: border-box !important;word-wrap: break-word !important;">架构师之路-分享可落地的技术文章 <p style="max-width: 100%;min-height: 1em;color: rgb(51, 51, 51);font-family: -apple-system-font, BlinkMacSystemFont, "Helvetica Neue", "PingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 17px;letter-spacing: 0.544px;text-align: justify;white-space: normal;background-color: rgb(255, 255, 255);box-sizing: border-box !important;word-wrap: break-word !important;"> <p style="max-width: 100%;min-height: 1em;color: rgb(51, 51, 51);font-family: -apple-system-font, BlinkMacSystemFont, "Helvetica Neue", "PingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 17px;letter-spacing: 0.544px;text-align: justify;white-space: normal;background-color: rgb(255, 255, 255);box-sizing: border-box !important;word-wrap: break-word !important;">相关推荐： <p style="max-width: 100%;min-height: 1em;color: rgb(51, 51, 51);font-family: -apple-system-font, BlinkMacSystemFont, "Helvetica Neue", "PingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 17px;letter-spacing: 0.544px;text-align: justify;white-space: normal;background-color: rgb(255, 255, 255);box-sizing: border-box !important;word-wrap: break-word !important;">《<a href="http://mp.weixin.qq.com/s?__biz=MjM5ODYxMDA5OQ==&mid=2651961812&idx=1&sn=592e3cc722bdfc4201d07cb1b087ed06&chksm=bd2d0c088a5a851eec1e01cea1d68a365edab46bc6985c469adb4b0df17f0e6c2f07bda8da47&scene=21#wechat_redirect" target="_blank" style="color: rgb(87, 107, 149);-webkit-tap-highlight-color: rgba(0, 0, 0, 0);max-width: 100%;box-sizing: border-box !important;word-wrap: break-word !important;">Google FileSystem架构启示</a>》 <p style="max-width: 100%;min-height: 1em;color: rgb(51, 51, 51);font-family: -apple-system-font, BlinkMacSystemFont, "Helvetica Neue", "PingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 17px;letter-spacing: 0.544px;text-align: justify;white-space: normal;background-color: rgb(255, 255, 255);box-sizing: border-box !important;word-wrap: break-word !important;">《<a href="http://mp.weixin.qq.com/s?__biz=MjM5ODYxMDA5OQ==&mid=2651961826&idx=1&sn=98f6ec5271c7a4153c3e50c7b8be4f33&chksm=bd2d0c3e8a5a8528177b34db26876e510486c78f331bd5e51082a22eda9d65b9bfc35abe1c53&scene=21#wechat_redirect" target="_blank" style="color: rgb(87, 107, 149);-webkit-tap-highlight-color: rgba(0, 0, 0, 0);max-width: 100%;box-sizing: border-box !important;word-wrap: break-word !important;">Google MapReduce解决什么问题？</a>》 <p style="max-width: 100%;min-height: 1em;color: rgb(51, 51, 51);font-family: -apple-system-font, BlinkMacSystemFont, "Helvetica Neue", "PingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 17px;letter-spacing: 0.544px;text-align: justify;white-space: normal;background-color: rgb(255, 255, 255);box-sizing: border-box !important;word-wrap: break-word !important;">《<a href="http://mp.weixin.qq.com/s?__biz=MjM5ODYxMDA5OQ==&mid=2651961881&idx=1&sn=a417acab437b7dea6a7ce6b5b9b31bfa&chksm=bd2d0fc58a5a86d30462ab461443683e164425136ba8169efb4cd9ea95e79bff74d3f25fdf0e&scene=21#wechat_redirect" target="_blank" style="color: rgb(87, 107, 149);-webkit-tap-highlight-color: rgba(0, 0, 0, 0);max-width: 100%;box-sizing: border-box !important;word-wrap: break-word !important;">MapReduce，颠覆了分层架构的本质？</a>》

Elasticsearch如何做到亿级数据查询毫秒级返回？

作者：微信小助手

<section style="box-sizing: border-box;font-size: 16px;"> <section style="box-sizing: border-box;" powered-by="xiumi.us"> <section style="margin-top: 10px;margin-bottom: 10px;box-sizing: border-box;"> <section style="padding-top: 10px;padding-right: 10px;padding-left: 10px;box-sizing: border-box;background-color: rgb(239, 239, 239);"> <section style="box-sizing: border-box;"> “ </section> <section style="display: inline-block;vertical-align: top;float: right;width: 90%;line-height: 1.5;font-size: 15px;color: rgb(89, 89, 89);box-sizing: border-box;"> 如果面试的时候碰到这样一个面试题：ES 在数据量很大的情况下（数十亿级别）如何提高查询效率？ </section> <section style="clear: both;box-sizing: border-box;"></section> </section> </section> </section> </section> <img class="rich_pages" data-copyright="0" data-ratio="0.48205928237129486" data-s="300,640" src="/upload/413de884be844596fd2c43f3193fb1e3.png" data-type="png" data-w="641" style=""> 这个问题说白了，就是看你有没有实际用过 ES，因为啥？其实 ES 性能并没有你想象中那么好的。 很多时候数据量大了，特别是有几亿条数据的时候，可能你会懵逼的发现，跑个搜索怎么一下 5~10s，坑爹了。 第一次搜索的时候，是 5~10s，后面反而就快了，可能就几百毫秒。 你就很懵，每个用户第一次访问都会比较慢，比较卡么？所以你要是没玩儿过 ES，或者就是自己玩玩儿 Demo，被问到这个问题容易懵逼，显示出你对 ES 确实玩的不怎么样？ <section class="" data-tools="135编辑器" data-id="39" data-color="#138bde"> <section class="" data-tools="135编辑器" data-id="39" data-color="#138bde" data-custom="#1e9be8"> <section> </section> </section> </section> 说实话，ES 性能优化是没有银弹的。啥意思呢？就是不要期待着随手调一个参数，就可以万能的应对所有的性能慢的场景。 也许有的场景是你换个参数，或者调整一下语法，就可以搞定，但是绝对不是所有场景都可以这样。 <section class="" data-tools="135编辑器" data-id="86122" data-color="#138bde"> <section> <section> <section> <section style="box-sizing: border-box;font-size: 16px;"> <section style="box-sizing: border-box;" powered-by="xiumi.us"> <section style="border-bottom-width: 1px;border-bottom-style: solid;border-bottom-color: black;margin-top: 0.5em;margin-bottom: 0.5em;line-height: 1.2;box-sizing: border-box;"> <section style="display: inline-block;border-bottom-width: 6px;border-bottom-style: solid;border-color: rgb(89, 89, 89);margin-bottom: -1px;font-size: 20px;color: rgb(89, 89, 89);box-sizing: border-box;"> 性能优化的杀手锏：Filesystem Cache </section> </section> </section> </section> </section> </section> </section> </section> 你往 ES 里写的数据，实际上都写到磁盘文件里去了，查询的时候，操作系统会将磁盘文件里的数据自动缓存到 Filesystem Cache 里面去。 <img class="rich_pages " data-croporisrc="/upload/37bc9c8439d751a982ba02711a24aa93.jpg" data-cropx1="0" data-cropx2="515" data-cropy1="44" data-cropy2="484" data-ratio="0.8543689320388349" data-s="300,640" data-type="jpeg" data-w="515" src="https://mmbiz.qpic.cn/mmbiz_jpg/tibrg3AoIJTtmGR5Eb1iaOWMib3auLw3FWr3vOYdA7POCribHibIDQia3SbdPcaJDrAYQdMz7gqHuMeRicRrr5AiablonA/640?wx_fmt=jpeg" style="box-sizing: border-box !important;word-wrap: break-word !important;width: 515px !important;visibility: visible !important;"> ES 的搜索引擎严重依赖于底层的 Filesystem Cache，你如果给 Filesystem Cache 更多的内存，尽量让内存可以容纳所有的 IDX Segment File 索引数据文件，那么你搜索的时候就基本都是走内存的，性能会非常高。 性能差距究竟可以有多大？我们之前很多的测试和压测，如果走磁盘一般肯定上秒，搜索性能绝对是秒级别的，1 秒、5 秒、10 秒。 但如果是走 Filesystem Cache，是走纯内存的，那么一般来说性能比走磁盘要高一个数量级，基本上就是毫秒级的，从几毫秒到几百毫秒不等。 这里有个真实的案例：某个公司 ES 节点有 3 台机器，每台机器看起来内存很多 64G，总内存就是 64 * 3 = 192G。 每台机器给 ES JVM Heap 是 32G，那么剩下来留给 Filesystem Cache 的就是每台机器才 32G，总共集群里给 Filesystem Cache 的就是 32 * 3 = 96G 内存。 而此时，整个磁盘上索引数据文件，在 3 台机器上一共占用了 1T 的磁盘容量，ES 数据量是 1T，那么每台机器的数据量是 300G。这样性能好吗？  Filesystem Cache 的内存才 100G，十分之一的数据可以放内存，其他的都在磁盘，然后你执行搜索操作，大部分操作都是走磁盘，性能肯定差。 归根结底，你要让 ES 性能好，最佳的情况下，就是你的机器的内存，至少可以容纳你的总数据量的一半。 根据我们自己的生产环境实践经验，最佳的情况下，是仅仅在 ES 中就存少量的数据，就是你要用来搜索的那些索引，如果内存留给 Filesystem Cache 的是 100G，那么你就将索引数据控制在 100G 以内。 这样的话，你的数据几乎全部走内存来搜索，性能非常之高，一般可以在1秒以内。 比如说你现在有一行数据：id，name，age .... 30 个字段。但是你现在搜索，只需要根据 id，name，age 三个字段来搜索。 如果你傻乎乎往 ES 里写入一行数据所有的字段，就会导致说 90% 的数据是不用来搜索的。 结果硬是占据了 ES 机器上的 Filesystem Cache 的空间，单条数据的数据量越大，就会导致 Filesystem Cahce 能缓存的数据就越少。 其实，仅仅写入 ES 中要用来检索的少数几个字段就可以了，比如说就写入 es id，name，age 三个字段。 然后你可以把其他的字段数据存在 MySQL/HBase 里，我们一般是建议用 ES + HBase 这么一个架构。 HBase 的特点是适用于海量数据的在线存储，就是对 HBase 可以写入海量数据，但是不要做复杂的搜索，做很简单的一些根据 id 或者范围进行查询的这么一个操作就可以了。 从 ES 中根据 name 和 age 去搜索，拿到的结果可能就 20 个 doc id，然后根据 doc id 到 HBase 里去查询每个 doc id 对应的完整的数据，给查出来，再返回给前端。 写入 ES 的数据最好小于等于，或者是略微大于 ES 的 Filesystem Cache 的内存容量。 然后你从 ES 检索可能就花费 20ms，然后再根据 ES 返回的 id 去 HBase 里查询，查 20 条数据，可能也就耗费个 30ms。 可能你原来那么玩儿，1T 数据都放 ES，会每次查询都是 5~10s，现在可能性能就会很高，每次查询就是 50ms。 <section class="" data-tools="135编辑器" data-id="86122" data-color="#138bde"> <section> <section> <section> <section style="box-sizing: border-box;font-size: 16px;"> <section style="box-sizing: border-box;" powered-by="xiumi.us"> <section style="border-bottom-width: 1px;border-bottom-style: solid;border-bottom-color: black;margin-top: 0.5em;margin-bottom: 0.5em;line-height: 1.2;box-sizing: border-box;"> <section style="display: inline-block;border-bottom-width: 6px;border-bottom-style: solid;border-color: rgb(89, 89, 89);margin-bottom: -1px;font-size: 20px;color: rgb(89, 89, 89);box-sizing: border-box;"> 数据预热 </section> </section> </section> </section> </section> </section> </section> </section> 假如说，哪怕是你就按照上述的方案去做了，ES 集群中每个机器写入的数据量还是超过了 Filesystem Cache 一倍。 比如说你写入一台机器 60G 数据，结果 Filesystem Cache 就 30G，还是有 30G 数据留在了磁盘上。 其实可以做数据预热。举个例子，拿微博来说，你可以把一些大 V，平时看的人很多的数据，提前在后台搞个系统。 每隔一会儿，自己的后台系统去搜索一下热数据，刷到 Filesystem Cache 里去，后面用户实际上来看这个热数据的时候，他们就是直接从内存里搜索了，很快。 或者是电商，你可以将平时查看最多的一些商品，比如说 iPhone 8，热数据提前后台搞个程序，每隔 1 分钟自己主动访问一次，刷到 Filesystem Cache 里去。 对于那些你觉得比较热的、经常会有人访问的数据，最好做一个专门的缓存预热子系统。 就是对热数据每隔一段时间，就提前访问一下，让数据进入 Filesystem Cache 里面去。这样下次别人访问的时候，性能一定会好很多。 <section class="" data-tools="135编辑器" data-id="86122" data-color="#138bde"> <section> <section> <section> <section style="box-sizing: border-box;font-size: 16px;"> <section style="box-sizing: border-box;" powered-by="xiumi.us"> <section style="border-bottom-width: 1px;border-bottom-style: solid;border-bottom-color: black;margin-top: 0.5em;margin-bottom: 0.5em;line-height: 1.2;box-sizing: border-box;"> <section style="display: inline-block;border-bottom-width: 6px;border-bottom-style: solid;border-color: rgb(89, 89, 89);margin-bottom: -1px;font-size: 20px;color: rgb(89, 89, 89);box-sizing: border-box;"> 冷热分离 </section> </section> </section> </section> </section> </section> </section> </section> ES 可以做类似于 MySQL 的水平拆分，就是说将大量的访问很少、频率很低的数据，单独写一个索引，然后将访问很频繁的热数据单独写一个索引。 最好是将冷数据写入一个索引中，然后热数据写入另外一个索引中，这样可以确保热数据在被预热之后，尽量都让他们留在 Filesystem OS Cache 里，别让冷数据给冲刷掉。 你看，假设你有 6 台机器，2 个索引，一个放冷数据，一个放热数据，每个索引 3 个 Shard。3 台机器放热数据 Index，另外 3 台机器放冷数据 Index。 这样的话，你大量的时间是在访问热数据 Index，热数据可能就占总数据量的 10%，此时数据量很少，几乎全都保留在 Filesystem Cache 里面了，就可以确保热数据的访问性能是很高的。 但是对于冷数据而言，是在别的 Index 里的，跟热数据 Index 不在相同的机器上，大家互相之间都没什么联系了。 如果有人访问冷数据，可能大量数据是在磁盘上的，此时性能差点，就 10% 的人去访问冷数据，90% 的人在访问热数据，也无所谓了。 <section class="" data-tools="135编辑器" data-id="86122" data-color="#138bde"> <section> <section> <section> <section style="box-sizing: border-box;font-size: 16px;"> <section style="box-sizing: border-box;" powered-by="xiumi.us"> <section style="border-bottom-width: 1px;border-bottom-style: solid;border-bottom-color: black;margin-top: 0.5em;margin-bottom: 0.5em;line-height: 1.2;box-sizing: border-box;"> <section style="display: inline-block;border-bottom-width: 6px;border-bottom-style: solid;border-color: rgb(89, 89, 89);margin-bottom: -1px;font-size: 20px;color: rgb(89, 89, 89);box-sizing: border-box;"> Document 模型设计 </section> </section> </section> </section> </section> </section> </section> </section> 对于 MySQL，我们经常有一些复杂的关联查询。在 ES 里该怎么玩儿，ES 里面的复杂的关联查询尽量别用，一旦用了性能一般都不太好。 最好是先在 Java 系统里就完成关联，将关联好的数据直接写入 ES 中。搜索的时候，就不需要利用 ES 的搜索语法来完成 Join 之类的关联搜索了。 Document 模型设计是非常重要的，很多操作，不要在搜索的时候才想去执行各种复杂的乱七八糟的操作。 ES 能支持的操作就那么多，不要考虑用 ES 做一些它不好操作的事情。如果真的有那种操作，尽量在 Document 模型设计的时候，写入的时候就完成。 另外对于一些太复杂的操作，比如 join/nested/parent-child 搜索都要尽量避免，性能都很差的。 <section class="" data-tools="135编辑器" data-id="86122" data-color="#138bde"> <section> <section> <section> <section style="box-sizing: border-box;font-size: 16px;"> <section style="box-sizing: border-box;" powered-by="xiumi.us"> <section style="border-bottom-width: 1px;border-bottom-style: solid;border-bottom-color: black;margin-top: 0.5em;margin-bottom: 0.5em;line-height: 1.2;box-sizing: border-box;"> <section style="display: inline-block;border-bottom-width: 6px;border-bottom-style: solid;border-color: rgb(89, 89, 89);margin-bottom: -1px;font-size: 20px;color: rgb(89, 89, 89);box-sizing: border-box;"> 分页性能优化 </section> </section> </section> </section> </section> </section> </section> </section> ES 的分页是较坑的，为啥呢？举个例子吧，假如你每页是 10 条数据，你现在要查询第 100 页，实际上是会把每个 Shard 上存储的前 1000 条数据都查到一个协调节点上。 如果你有 5 个 Shard，那么就有 5000 条数据，接着协调节点对这 5000 条数据进行一些合并、处理，再获取到最终第 100 页的 10 条数据。 分布式的，你要查第 100 页的 10 条数据，不可能说从 5 个 Shard，每个 Shard 就查 2 条数据，最后到协调节点合并成 10 条数据吧？ 你必须得从每个 Shard 都查 1000 条数据过来，然后根据你的需求进行排序、筛选等等操作，最后再次分页，拿到里面第 100 页的数据。 你翻页的时候，翻的越深，每个 Shard 返回的数据就越多，而且协调节点处理的时间越长，非常坑爹。所以用 ES 做分页的时候，你会发现越翻到后面，就越是慢。 我们之前也是遇到过这个问题，用 ES 作分页，前几页就几十毫秒，翻到 10 页或者几十页的时候，基本上就要 5~10 秒才能查出来一页数据了。 有什么解决方案吗？不允许深度分页（默认深度分页性能很差）。跟产品经理说，你系统不允许翻那么深的页，默认翻的越深，性能就越差。 类似于 App 里的推荐商品不断下拉出来一页一页的；类似于微博中，下拉刷微博，刷出来一页一页的，你可以用 Scroll API，关于如何使用，自行上网搜索。 Scroll 会一次性给你生成所有数据的一个快照，然后每次滑动向后翻页就是通过游标 scroll_id 移动，获取下一页、下一页这样子，性能会比上面说的那种分页性能要高很多很多，基本上都是毫秒级的。 但是，唯一的一点就是，这个适合于那种类似微博下拉翻页的，不能随意跳到任何一页的场景。 也就是说，你不能先进入第 10 页，然后去第 120 页，然后又回到第 58 页，不能随意乱跳页。 所以现在很多产品，都是不允许你随意翻页的，App，也有一些网站，做的就是你只能往下拉，一页一页的翻。 初始化时必须指定 Scroll 参数，告诉 ES 要保存此次搜索的上下文多长时间。你需要确保用户不会持续不断翻页翻几个小时，否则可能因为超时而失败。 除了用 Scroll API，你也可以用 search_after 来做。search_after 的思想是使用前一页的结果来帮助检索下一页的数据。 显然，这种方式也不允许你随意翻页，你只能一页页往后翻。初始化时，需要使用一个唯一值的字段作为 Sort 字段。 作者：节操泛滥的程序员 编辑：陶家龙、孙淑娟 出处：https://zhuanlan.zhihu.com/p/60458049 <img class="rich_pages" data-copyright="0" data-ratio="0.3939393939393939" src="/upload/58a14061a632a0fe87d40beb73c1aa.gif" data-type="gif" data-w="660" style=""> <section style="box-sizing: border-box;font-size: 16px;"> <section style="box-sizing: border-box;" powered-by="xiumi.us"> <section style="margin-top: 0.5em;margin-bottom: 0.5em;box-sizing: border-box;"> <section style="font-size: 15px;border-style: solid;border-width: 0px 0px 1px;color: rgb(89, 89, 89);border-bottom-color: rgba(215, 215, 215, 0.960784);box-sizing: border-box;"> 精彩文章推荐： </section> </section> </section> </section> <a href="http://mp.weixin.qq.com/s?__biz=MjM5ODI5Njc2MA==&mid=2655824391&idx=1&sn=ac183b0cc7b1ee2ea0c10c1d4abf6fc0&chksm=bd74e7d08a036ec6bc54c31519a1391758741977f646f711bc17e2be69b1f333ea2ee0078137&scene=21#wechat_redirect" target="_blank" data-itemshowtype="0" style="font-size: 14px;color: rgb(89, 89, 89);letter-spacing: 1px;text-decoration: none;" data-linktype="2">搞定高并发，岂能不懂Synchronized底层原理？</a> <a href="http://mp.weixin.qq.com/s?__biz=MjM5ODI5Njc2MA==&mid=2655824323&idx=1&sn=2cd6852e7baae4b00c68d2678b5e23cc&chksm=bd74e4148a036d02831449be2301f2c83faabdd03760ba970a63a1d5c2c19c603b4108ebcc77&scene=21#wechat_redirect" target="_blank" data-itemshowtype="0" style="font-size: 14px;color: rgb(89, 89, 89);letter-spacing: 1px;text-decoration: none;" data-linktype="2">超详细的Elasticsearch高性能优化实践</a> <a href="http://mp.weixin.qq.com/s?__biz=MjM5ODI5Njc2MA==&mid=2655824393&idx=1&sn=5a31b81285dca2818cecc898d42760ab&chksm=bd74e7de8a036ec81b2c08d19a71a04e43b575e5a1959d852d59410fb7bd3a31087dde560d5d&scene=21#wechat_redirect" target="_blank" data-itemshowtype="0" style="font-size: 14px;color: rgb(89, 89, 89);letter-spacing: 1px;text-decoration: none;" data-linktype="2">在阿里，我如何做好一个项目的启动？</a>

文章列表