25,980
社区成员
发帖
与我相关
我的任务
分享200分 高手进来-- 图片服务器的单点、balance、ha
项目中要处理海量图片，由于公司资金有限，打算全部用普通pc，通过集群来实现容量的扩展。通过hash将图片分散保存到集群中的任意一个服务器上。初期计划使用3台PC，每个PC搭配1T硬盘。
现在有个问题：我想对每一个PC做一个负载均衡，即为每一个PC再搭配一个slave，上传时，图片会同时保存到主/从机器，有2个拷贝；访问某张图片时，由于一张图片在两台PC上都有副本，所以随机将请求转发到一台PC上，这样既能均衡，又能解决单点故障。
不知道这样的架构行不行？
未来的扩展性如何，配置是否麻烦（例如，未来有50台PC做服务器，同时为每一个PC配置一个slave，这样可能要配置很多信息）？
有没有考虑过这样的架构？
有没有人实际搭建过一个大容量、高并发、多副本的图片服务器架构？你们的架构是怎样的？
请高手进来说一说
现在有个问题：我想对每一个PC做一个负载均衡，即为每一个PC再搭配一个slave，上传时，图片会同时保存到主/从机器，有2个拷贝；访问某张图片时，由于一张图片在两台PC上都有副本，所以随机将请求转发到一台PC上，这样既能均衡，又能解决单点故障。
不知道这样的架构行不行？
未来的扩展性如何，配置是否麻烦（例如，未来有50台PC做服务器，同时为每一个PC配置一个slave，这样可能要配置很多信息）？
有没有考虑过这样的架构？
有没有人实际搭建过一个大容量、高并发、多副本的图片服务器架构？你们的架构是怎样的？
请高手进来说一说
...全文
请发表友善的回复…
发表回复
pricks 2014-06-12
- 打赏
- 举报
多集群之间数据同步小到机柜间、大到异地IDC，一般都需要使用专线的方式。淘宝的缓存控制是有他自己写的一套方案的，他们介绍说能达到秒级失效，缓存方案从本机缓存=>>集中式缓存=>>CDN等等（程序员杂志2014年1月刊有系列文章）
我很赞同两位关于所谓完美架构的观点，一种架构方案，他通常都是在一定时期内匹配一定的业务需求，这个匹配一定也是业务需求与效费比的妥协，与此同时，架构要能够做到快速的迭代，不断适应变化，这就是好的架构。好的架构从数学角度看，他也是简洁精炼的，所谓的重剑无锋大巧若工无外如是了[/quote]
看来还真有多个集群之间的数据同步啊。这个一直存在于我的想象中。如果真要做到这一点，真的只能自己另外写套方案，控制同步的方向，多个点到点，或者多个点到多点。
谢谢这位大神的赐教！
pricks 2014-06-12
- 打赏
- 举报
这个倒也不失为一个好主意
hemaliu 2014-06-11
- 打赏
- 举报
cdn的机制倒是不难理解的，不过要真如我所说的那种要求来的话，其运维的确是相当复杂了，不管是应用程序级的同步还是内核机制，或者供应商提供的配置，都不是一件容易的事。
并且cdn一般小公司也玩不起的，而且很不幸，我所在的公司就玩不起。
不过在我看了大量的cdn、hdfs以及中小规模的图片服务器集群的理论和实践的文章之后，我心中总是有一种隐隐的担忧和缺憾。
缺憾是，这么多的文章，我居然就没找到一篇能够同时满足图片服务器容量可扩展性和负载均衡可扩展性的方案，所有的方案，要么只解决扩容性问题（散列存储），要么只解决load balance问题，没有谁提出来要同时解决这两个问题的。当然，如果非要同时解决，hdfs是个不错的选择，但是对于中小规模的站点来说，hdfs并不是一个好的抉择。
即便很多大牛，包括看了EMC的，百度，淘宝等公司技术人员写的关于hdfs理论方面的文章，大部分只是讲解hdfs内部是如何实现大文件分段存储和备份的，但是从来没有谁提及过，hdfs为什么能够同时满足无限扩容（理论上）和同一个文件的均衡访问？为什么？没人提过，没人想过，我觉得这真是一种悲哀。事实上，我觉得这是一个很好的研究课题，在我看来，hdfs的均衡访问与扩容不是一个对称的，是不优美的。例如，两个web服务器实现集群，可以通过将其权重设置成各50%来实现均衡或轮询访问，但是hdfs呢，是如何实现压力转移的，是均衡的吗，是随机的吗？
不过很多人倒是提到了hdfs的所谓nn的双机热备机制，我觉得这个倒不那么重要，因为这个理论上有很成熟的解决方案，facebook提出了一种，淘宝提出了自己的，百度也有自己的解决方案。
我感到担忧的是，如果只对图片服务器进行扩容集群，那么压力均衡就是一个问题；如果只转移访问压力，则扩容又是一个问题。我没找到任何一个完美的方案。可能我过于追求完美了。
拿淘宝来说，其tfds 1.0版本也开源了，我看了下机制，对hdfs的改动并不是很大，这个分布式系统本身是没有问题的。但是我对这个系统能够支持多达500T的图片、能够同时一天300多万如此巨大的访问量的承载能力，仍然感到很多疑惑。tfds在全国有没有多个分布式群？如果有，这些分布式群之间是如何同步图片的呢？虽然tfds在前端使用了一级和二级缓存来把90%的图片访问都挡在了tfds的门口，但是还是会存在多个分布式群之间如何同步新图片的问题？cdn分发？还是自己开发的应用程序级别的同步机制？
可能我想的太多了。不过我想设计的架构其实就是很简单的，拿三四台PC来扩容，同时对每一个节点做双机负载。就是这么一个简单的架构，但是我从没看到有人提出过这个架构，而我本身对其深入的研究下去后，发现越来越复杂，导致复杂到没有尽头。
[/quote]
你所谓想多了的其实就是我说的rehash成本问题，这里的成本不是狭义的资金成本，更是我们最为关注的数据准确性和响应。在扩容、故障转移的时候都涉及到了rehash，同时rehash也决定了你的负载均衡时的路由策略、均衡算法等等。
多集群之间数据同步小到机柜间、大到异地IDC，一般都需要使用专线的方式。淘宝的缓存控制是有他自己写的一套方案的，他们介绍说能达到秒级失效，缓存方案从本机缓存=>>集中式缓存=>>CDN等等（程序员杂志2014年1月刊有系列文章）
我很赞同两位关于所谓完美架构的观点，一种架构方案，他通常都是在一定时期内匹配一定的业务需求，这个匹配一定也是业务需求与效费比的妥协，与此同时，架构要能够做到快速的迭代，不断适应变化，这就是好的架构。好的架构从数学角度看，他也是简洁精炼的，所谓的重剑无锋大巧若工无外如是了
巴山虎 2014-06-10
- 打赏
- 举报
话不多说，在你硬件不给力的情况下，建议花点钱使用云存储。什么腾讯云微软云某某云，哪个便宜用那一个。
总之应该比你的硬件投入要小，而且速度更快。
MiceRice 2014-06-06
- 打赏
- 举报
我认为这个是：实际需求、投资代价 和 技术可行性 三者相互妥协的结果。
有什么规模的实际需求，在现行技术可行性下就对应什么方案，同样就会有对应的投资代价（包括技术复杂度度等）。
目前并没有一种技术是决定性压倒一切的（估计十年内也不会有）：
1、完全适应低业务量和高业务量；
2、完全适应高读取和高写入；
3、完全适应属地集中式服务和广域分布式服务；
4、横向扩展与性能收益完全线性化。
架构师所做的事情，就是在满足实际需求的目标下，分析、拆分、重组系统需求，然后用不同的技术方案去组合匹配，得到最终的结果。
淘宝我觉得它在性能和时效性上是做了不少的妥协的，你新发布一个商品，从你发布到它实际上架就有比较长的时延，名义上是“审核”，实际上各种索引、分发、排名等的预处理，必定是关键原因之一（这就是系统需求反向影响业务需求）。
另一个工作是“业务纵向切分”，比如：页面和图片不使用同一套HDFS，甚至更细粒度的业务纵向切分。
总的来说我不认为有绝对意义的“完美方案”，但是随着投资代价的增加，可以比较好的逼近这个方案。但是投资代价又意味着实际业务规模是否值得你投入这个代价（公司规模？用户规模？收益规模？机房设备配套等等？）
HDFS可以实现一定程度的压力转移，但建立在副本数量的基础上，比如你有12块磁盘分布在4台物理主机上，副本冗余度配置是3。那么HDFS对于访问请求就会在这3个副本之间进行均衡（一般是随机），当然这种均衡不会太理想化，忙闲可能会高达50%的差异，另外还可能存在物理机压力分摊不均问题，但确实它有均衡考虑。也有很多人在探讨怎么改进它，比如：http://www.cnki.com.cn/Article/CJFDTotal-JGXB201303017.htm
另外，HDFS也不能支持无限扩容，主要是受到NameNode限制，但从目前业界需求而言，已经很好了。
最后呢，确实存储扩容和横向扩展是两个有关联的命题，常规解决方案下，是将其作为两个不同的层面来解决的，我以不缺钱传统方案来举例：
◎ 存储扩容，在使用了商业存储解决方案的情况下，就是存储服务器加磁盘柜，你要扩容就是拼命增加磁盘柜；
◎ 横向扩展，前端不断增加Web服务器，不管你是Tomcat、Apache还是Ngnix，然后用硬件负载均衡设备进行请求分配（硬件负载均衡自身支持横向多机集群）；
◎ CDN，商业存储解决方案都支持存储级的广域准实时复制方案，然后是DNS负载均衡引领下的横向扩展集群组；有钱就天南地北多盖数据中心吧。
pricks 2014-06-06
- 打赏
- 举报
另外，对淘宝图片架构中的一级和二级缓存的研究，也使我深陷沼泽无法自拔。
在这里，我碰到了与图片集群一样的困惑。
首先，由于单台服务器的内存有限，就算其有160G的内存，也还是无法缓存整个淘宝多达500多T的图片，所以，无论是一级缓存，还是二级缓存，淘宝必然也做了内存散列存储的集群架构。例如，一个集群中有300台、160G的PC，那么总的缓存空间可以达到300×160的巨大容量，这样的容量差不多够了，即使不够，也还可以继续添加新的PC来解决。
但是做了这样的架构之后，我的担心又来了，万一其中一个服务器down掉了，也意味着其中所有的缓存图片都失效了。那么淘宝有没有什么单点故障转移机制呢？如果有，对这300台PC的每一台PC都配置一台slave，那这个架构一下载就复杂了。
如果，可以有单点机制，那么再加个balance，也是可以理解的吧。问题是，如果淘宝真的对一级和二级缓存做了balance，是如何实现的呢？是对这300台PC的每一台做balance，还是对整个集群做balance，例如在其他dns上再加集群？
焦虑…………………………
pricks 2014-06-06
- 打赏
- 举报
cdn的机制倒是不难理解的，不过要真如我所说的那种要求来的话，其运维的确是相当复杂了，不管是应用程序级的同步还是内核机制，或者供应商提供的配置，都不是一件容易的事。
并且cdn一般小公司也玩不起的，而且很不幸，我所在的公司就玩不起。
不过在我看了大量的cdn、hdfs以及中小规模的图片服务器集群的理论和实践的文章之后，我心中总是有一种隐隐的担忧和缺憾。
缺憾是，这么多的文章，我居然就没找到一篇能够同时满足图片服务器容量可扩展性和负载均衡可扩展性的方案，所有的方案，要么只解决扩容性问题（散列存储），要么只解决load balance问题，没有谁提出来要同时解决这两个问题的。当然，如果非要同时解决，hdfs是个不错的选择，但是对于中小规模的站点来说，hdfs并不是一个好的抉择。
即便很多大牛，包括看了EMC的，百度，淘宝等公司技术人员写的关于hdfs理论方面的文章，大部分只是讲解hdfs内部是如何实现大文件分段存储和备份的，但是从来没有谁提及过，hdfs为什么能够同时满足无限扩容（理论上）和同一个文件的均衡访问？为什么？没人提过，没人想过，我觉得这真是一种悲哀。事实上，我觉得这是一个很好的研究课题，在我看来，hdfs的均衡访问与扩容不是一个对称的，是不优美的。例如，两个web服务器实现集群，可以通过将其权重设置成各50%来实现均衡或轮询访问，但是hdfs呢，是如何实现压力转移的，是均衡的吗，是随机的吗？
不过很多人倒是提到了hdfs的所谓nn的双机热备机制，我觉得这个倒不那么重要，因为这个理论上有很成熟的解决方案，facebook提出了一种，淘宝提出了自己的，百度也有自己的解决方案。
我感到担忧的是，如果只对图片服务器进行扩容集群，那么压力均衡就是一个问题；如果只转移访问压力，则扩容又是一个问题。我没找到任何一个完美的方案。可能我过于追求完美了。
拿淘宝来说，其tfds 1.0版本也开源了，我看了下机制，对hdfs的改动并不是很大，这个分布式系统本身是没有问题的。但是我对这个系统能够支持多达500T的图片、能够同时一天300多万如此巨大的访问量的承载能力，仍然感到很多疑惑。tfds在全国有没有多个分布式群？如果有，这些分布式群之间是如何同步图片的呢？虽然tfds在前端使用了一级和二级缓存来把90%的图片访问都挡在了tfds的门口，但是还是会存在多个分布式群之间如何同步新图片的问题？cdn分发？还是自己开发的应用程序级别的同步机制？
可能我想的太多了。不过我想设计的架构其实就是很简单的，拿三四台PC来扩容，同时对每一个节点做双机负载。就是这么一个简单的架构，但是我从没看到有人提出过这个架构，而我本身对其深入的研究下去后，发现越来越复杂，导致复杂到没有尽头。
MiceRice 2014-06-06
- 打赏
- 举报
你的规模似乎还达不到两者都需要使用的程度；此外你的需求也许不合适使用CDN。
在使用CDN的情况下，一般来说仍然是保持只有一个主站负责更新，其它都是镜像；你的需求提及会存在修改需求，不清楚这个修改频度 和 时效性 要求如何，如果频度高或实时性要求高，用CDN的话会比较麻烦。
主站向其它HDFS的同步机制，要么就是程序级负责完成（更新时同步生成分发任务项，然后批处理程序轮询任务逐笔完成分发，可设置优先级），要么就是在HDFS上二次开发完成。只要保证只有一个主站负责更新（One Single Truth），倒谈不上分发复制的难度会有多高。
如果你想多个CDN都可以进行更新，那么结构就会复杂多了，相当之不推荐；一般性方案是：
1、分站接收到更新需求后，先向主站发出更新请求；（这个要走内部专网或专线以保证性能）
2、主站更新成功，反馈分站，分站本地更新；
3、主站后台批处理分发到其它分站；
4、各环节因为实际上是“分布式事务”，所以要有大量状态维护机制和容错机制，保证“最终一致性”。
如果打算让CDN之间以网格方式全部都可以互相直接分发更新，是不推荐之中的不推荐，主要是其保障机制和算法复杂度对于一般公司来说很难以承受。
pricks 2014-06-06
- 打赏
- 举报
还有最后一个问题，希望楼上的大神兄弟能够不吝赐教。
就是如果把图片服务器，例如HDFS，与CDN相结合，这个有没有什么实际的例子？CDN如果是单点对多层、多点的定向复制，原理上不难理解。
但是如果存在多个HDFS群，例如每一个集群都存在于不同的DNS中，并且需要让其中的一个HDFS群向其他HDFS群同步复制文件，这样的架构，想想都挺恐怖的，即使不恐怖，配置起来也是相当的繁琐。
MiceRice 2014-06-06
- 打赏
- 举报
愧不敢当。
我比较赞同你的理解。即便是Google，他们的架构也是随着据规模提升做过多次的全面升级，毕竟架构这种东西除了投入代价以外，还受到当时技术发展程度的制约。比如人工智能的发展程度、晶体管集成度、CPU多核技术发展程度、网卡网线的链路容量、甚至散热制冷系统 等等～～～
相互讨论，互相促进～～ 
pricks 2014-06-06
- 打赏
- 举报
这段文字真是精彩绝伦，精彩至极！在我看来，犹如读了一篇史上最灿烂辉煌、最富哲理之诗篇，让我一解长久以来心底深处的愁闷，给我的思想插上飞翔的翅膀，飞向那高耸入云的山顶之巅。
真不是拍马屁。我为了寻找我心中那理想的图片服务器架构，研究好几个月了，心中一直放不下，但又拿不起。
这段文字，让我意识到，我真的太过于追求完美了，贬义说法就是太固执、钻牛角尖、走死胡同。
不管淘宝这样的大公司也好，还是像我们一样的小公司也罢，没有任何人能够设计一种绝对意义上的完美架构，能够解决一切问题，如你所说，又能低成本，又能大量读和写，又能同时支持扩容和均衡，又能同时支持局域和广域上的大批量访问，同时还十分易搭建、易部署、易配置、易运维。其实我一直在苦苦思索的就是这样的一种架构，但是直到看到你的这段文字，我才真的清醒了，这种架构基本是不可能实现的，不管投入多少资金、多少人力、多长时间。
一开始只能是先搭建一个能够满足需求的架构，够用就行。当然设计之初，是需要考虑以后的扩张性，但是不代表现在就设计出来。
架构只能是随着业务规模不断拆散、切割、重组、扩展，够用就行。没有谁能够一开始就能设计出一种完美的架构，并且在以后也不行。诚如你所言，只能在实际的架构重组中无限接近完美，但永远达不到完美。
我一开始研究完几个架构，并亲自部署实践后，我呵呵了，以为所谓架构，不过如此。可是当我想设计一种近乎完美的架构时，却又发现自己好像啥都不会了，显得十分的无力和无奈。
真的要十分感谢你的这段文字。
你说的“业务纵向切分”，这是一个非常重要的概念，让我隐隐找到了一个方向。之前我在研究分布式缓存时，曾经想过如何近乎无限地扩展容量这个命题，当时也想到了根据业务进行纵向切分，例如日志缓存单独组群，博客的缓存单独组群，这样可以有多个集群，并且相互之间无需数据复制。如果日志缓存集群不够用了，还可以再对日志这个数据本身进行进一步切割，进一步分群，例如根据时间、根据用户地域、根据日志类型等。但是在我研究hdfs后，竟将这个重要的概念忘记了，一心想着如何设计出一个完美的、能解决一切问题的架构来。
hemaliu 2014-06-05
- 打赏
- 举报
我说的Rehash成本问题是针对楼主提出的方案来说的，HDFS当然没有rehash的问题，他是通过NameNode来解决的，不过这也带来了NameNode单点问题，到目前为止这个问题的解决方案都不算完美；
用HDFS相比楼主的解决方案要更加稳定一些，但HDFS更适合只读数据的写，虽然图片写了就不用改，但楼主的都是小图片，用HDFS的确会出现空间浪费的情况，除非多图片合并写入到一个块中，这样的话估计楼主宁愿选择自己的方案，只要解决rehash时数据不做大规模迁移即可
是二子啊 2014-06-04
- 打赏
- 举报
膜拜一下海哥。
我想了下，没想到云存储。虽然公司在用，可是没想起来。
只想到了，把图放在一个服务器上，用ＳＳＤ在存储，用多太PC做请求分发。不知道这样会不会有读取问题？
MiceRice 2014-06-04
- 打赏
- 举报
你期望的模型不同于一般的CDN方式，你又希望不要重复存放太多副本（浪费空间），又希望能有分摊压力的效果。
基本上可选方案只有网格存储（云存储），比如 Apache HDFS，然后可以根据分摊压力的期望效果选则副本数量。
一台PC服务器可以带多个磁盘，并增加一个SSD板卡作为缓存盘，可以大大提升热点文件命中率。
另外的考虑就是关于热点非热点生命周期问题；如果能够增加自己的算法系统，区分出专门服务于热点的多副本集群 和 非热点的少副本集群，然后再定期将文件进行搬移，效果会更好。
pricks 2014-06-04
- 打赏
- 举报
我没明白你说的意思。为每个PC搭配1T的硬盘，以后不会增加的。若单个PC容量太大，意味着存储了百万计的图片（小图片），同时也意味着这台服务器可能会有高并发的访问量。
我主要是想问问有没有设计过既能扩容、又能解决单点故障和单点负载均衡的图片服务器架构？
是二子啊 2014-06-04
- 打赏
- 举报
虽然我没有做过图片的，不过觉得你的思路是不是有问题?
假设你有50台PC，随着图片的增多，是不是你每个ＰＣ上都要准备那么多硬盘啊？
这样不麻烦么？
有点想法，先mark一下，开会去了。回来再说。
MiceRice 2014-06-04
- 打赏
- 举报
关于服务器SSD这个，是有解决方案的，上次听到淘宝的典型配置是：12块磁盘配置一块SSD板卡，作为缓存使用是可以用操作系统级别插件完成；另外之前曾看到新版本的HDFS（还是啥）也能支持配置不同访问速度级别的存储类型，让高速存储为低速存储做缓存。
自己开发算法的主要问题是稳定性和高可靠性不太容易得到保障，时间越长可维护性约成为问题，所以即便通用方案不是最优，也优先考虑通用方案；淘宝等团队，往往选择在开源的基础上进行二次开发和改造。
关于块大小问题，其实HDFS虽然块大小比较大，但一个文件并非独享一个块，所以空间浪费问题没有你想象的那么严重。设置大块主要还是从寻址、冗余、管理上的速度或便利性考虑。
关于扩容时的Rehash，没记错的话，HDFS已经有很好的优化了，谈不上有恐怖的开销；而且，只要涉及网格存储类，扩容和故障发生时都必然会有这类额外开销。
你提及改动问题，这个可能真是个问题，HDFS对于高并发频度的修改，支持的不算好。毕竟涉及到块操作。
最后，应该多花点时间研究几种云存储技术方案，很值得滴；即便是你最终决定自己去实现，了解清楚各通用技术各自优缺点以便组合出自己最佳适应性的方案，也是非常非常有帮助的～～～
pricks 2014-06-04
- 打赏
- 举报
这个方案最大的问题是：当扩容时Rehash的成本比较恐怖，除非你的负载均衡算法有修正优化[/quote]
是的，没有最完美的架构，只有最合适的架构，并且随着环境和用户变迁，架构也需要做相应调整才行。而架构调整的两个依据就是分析网络IO和磁盘IO。谁不足，就扩展谁。
关于rehash，我研究分布式ehcache时，里面有个一致性散列算法，倒是可以借鉴到图片服务器扩容上来。
pricks 2014-06-04
- 打赏
- 举报
谢谢这位大神！你说的方案说到我心里去了。
SSD应该是固态硬盘吧，这个之前一直没关注过，不过知道其原理，相当于内存，存取速度与内存基本在一个数量级吧，也不会存在磁盘机械寻址的开销了。不过要将其配置成缓存，不知道这个怎么设置？如果用内存会的，但是硬盘该怎么办呢？还是专门写个程序，把读取到的图片专门在SSD上保存一份，然后读取的时候，先从SSD中读取，若SSD中没有，再去磁盘中读取？
关于HDFS，考虑过，也搭建过，不过我觉得针对目前三四台服务器就搞这个，是不是有点大材小用。并且HDFS的文件分割是60M，而我们的图片基本都是小文件，几K到十几K，这样的话，HDFS反而效率低下。不过HDFS未来的扩展性倒是非常不错的，不需要去修改啥配置了。另外，我们的图片用户会经常修改，即使是十年前的，也可能会改，跟新上传的图片一样对待。而HDFS只支持增量方式的添加新图，不支持修改和删除。综上总总原因，我一开始设计架构时，就把HDFS给排除掉了。不过也研究了另外几家的分布式FS，可能有的比较合适，但是初期毕竟PC才几台，所以总感觉貌似是大材小用。
关于你说的热点图，这个我研究过，例如像论坛，可以把过去一年中的所有图片放到一台服务器上，因为越老的图，访问概率越低。但是我们这个平台，每一张图，用户都可能会改。因为只要用户一直使用这个系统，则其就可能修改其历史上传的所有图片。所以我暂时还没找到啥热点图。
另外，关于CDN，我研究过，但因为公司不大，所以一直没亲自实践过，也没具体看到过人家的例子。不过我一直有一个疑问。像新闻、论坛、博客等系统，倒是非常适合用CDN，因为越老的新闻、帖子、博文，访问的概率就越低。所以使用CDN，只需把最新的网页或静态文件推送到各个前端web服务器下，这样web服务器中不需要多么大的硬盘空间，即可容纳相关静态文件。但是，像图片服务器，例如总共有10T的图片，不可能把这10T的图片都cdn到各个前端服务器上吧。如果使用hash算法将其散列大不同服务器上，那结果就相当于将图片由一个散列集群中推送到另一个散列集群中，这样配置起来貌似又比较复杂。我简直不知道要怎么配置了。
还希望仁兄进一笔赐教！
hemaliu 2014-06-04
- 打赏
- 举报
这个方案最大的问题是：当扩容时Rehash的成本比较恐怖，除非你的负载均衡算法有修正优化
加载更多回复（1）
