×

深圳网站建设—APP开发—网站制作—小程序开发_博纳网络公司

0755 -
82538016
82560826
网站制作资讯

社交APP开发聊天功能缓存架构升级实操流程

文章编辑:网站建设 文章来源:APP开发 浏览量:

  我们在开发社交App后台架构的初期,一般采用单台缓存的架构,随着业务的发展,单缓存的架构会受到单机内存限制。在大型的社交App中,虽然没必要把所有的数据都放入缓存,但为了保证核心缓存(保存了用户最近的内容)的命中率达到99%,也需要大量的缓存。单台服务器显然没法满足缓存所有数据的要求。针对这个问题,深圳APP开发公司总结出以下解决方案:
1.布式缓存解决法
 为了解决单机内存受限的问题,社交App后台引入了分布式缓存的架构,如图9- 24所示。
社交APP开发聊天功能升级解决方案示意图9-24分布式缓存的架构
后台使用了分布式缓存后,每台缓存服务器缓存总数据量的部分,这时要解决两个问题
·后台中有多台缓存服务器,怎么确定某个数据缓存在哪台缓存服务器?
·怎样才能让数据均衡地分布到缓存服务器上,以免造成有的缓存服务器缓存的数据多,有的缓存服务器缓存的数据少?
  上面两个问题可用余数hash的方案解决:用服务器的数量除以缓存数据的Key的hash值,余数为对应的缓存服务器的下标编号0例如,对于Key为“jeff”的数据.hash值(Java的hashCode返回值)为3258171,用服务器数目3除以该值,得到余数0,因此该数据存储在“缓存服务器O”。
  余数hash最大的缺点是当增加、减少缓存服务器时,会造成缓存服务器结果的大震荡。例如,缓存服务器从3台变成了4台,对于Key为“jeff”的数据,hash值(Java的hashCode返回值)为3258171,用服务器数目4除以该值,得到余数3,因此把数据从存储在“缓存服务器0”变为存储在“缓存服务器3”,如图9-25所示。
社交APP开发聊天功能缓存升级方案示意图9-25 Key为"jeff”的数据命中缓存服务器的不同情况
  我们APP开发爱好者可以计算出来,当缓存服务器的数目从3台升到4台,大约有75% (3/4)被缓存的数据不能命中缓存服务器,随着服务器集群规模的增大,这个比值会不断加大,整体的命中率下降得非常快。
  在App后台中,大部分业务请求所需的数据是通过缓存获取的,只有少部分请求会穿透到数据库,因此数据库的负载能力是按照缓存承担了大部分请求的情况设计。当因为增加缓存服务器造成缓存没法命中,大量的业务请求穿透到数据库会造成数据库的压力过大,甚至造成数据库宕机,从而使业务瘫痪,这个结果显然是不能接受的。
  为了使新增缓存服务器不至于影响大部分缓存的命中率,需要使用“一致性hash算法”这种更合理的hash算法。
  一致性哈希算法是1997年由麻省理工学院提出的种分布式哈希(DHT)实现算法。其基本原理是构造个长度为0—4294967296的圆环(称为一致性hash环),根据缓存服务器名称的hash值(分布范围是。-4294967296)把缓存服务器放置在这个hash环上。当缓存的请求到达,根据缓存数据的Key计算得到其hash值(分布范围同样是0-4294967296),根据这个hash值判断缓存数据是否命中缓存服务器,如果没有命中缓存服务器,则顺时针在hash环上查找距离这个Key的hash值最近的缓存服务器。
  APP开发公司下面举个例子说明一致性哈希算法的工作流程。在一致性哈希环下,存在3台缓存服务器的情况,Key值是“jeff”的数据命中缓存服务器的情况如图9-26所示。
  按照一致性哈希算法(顺时针查找的特性),在只有3台缓存服务器的时候.hash值范围是(3294967296 - 4294967296,0~1294967296)的Key都会命中缓存服务器0。
  当缓存服务器从3台加至4台,Key值是“jeff”的数据命中缓存服务器的情况如图9-27所示。
社交APP开发升级示意图9-27增加缓存服务器后的一致性啥希环
  当增加了一台缓存服务器4(11ash值是1094967296)后,hash值范围是3294967296- 4294967296,0--1094967296)的Key会命中缓存服
务器4.hash值范围是1094967297'-1294967296的Key会命中缓存服务器0。因此可看出,在使用一致性哈希算法的情况下,增加了一台缓存服务器后命中率受影响的Key只有[(4294967296-3294967296)+(1094967296-0)]/4294967296=0. 2549=25.49%.这个数值比起之前余数hash75%的值少多了。
  但一致性哈希算法还有问题:新增了台缓存服务器4后,原来落在缓存服务器。的请求现在由缓存服务器4和缓存服务器。共同承担,但落在缓存服务器3和缓存服务器2上的请求不变,这就意味着缓存服务器3和缓存服务器2缓存的数据量和负载压力比起缓存服务器4和缓存服务器0重多了。如果4台缓存服务器的配置都是一样,那么这个结果是不理想的,没法充分利用每台缓存服务器。
  该问题可以通过引入虚拟节点解决。在上面的例子中,一台缓存服务器只对应一个hash值,如果杷台缓存服务器对应两个hash值(一个真实节点,一个虚拟节点),甚至是多个hash值(多个虚拟节点)呢?这样新加入台缓存服务器,将会均匀地影响已经存在的缓存服务器并分摊原来服务器集群中的负载。新的一致性哈希算法环如图9-28所示。
好了,APP开发公司本文关于我们在社交APP升级开发时的解决方案就分享到这里,希望能给你的APP开发工作带来帮助,谢谢关注,博纳网络编辑整理。

当前文章链接:/construction/appkaifa/1797.html
如果您觉得案例还不错请帮忙分享:

[声明]本网转载网络媒体稿件是为了传播更多的信息,此类稿件不代表本网观点,本网不承担此类稿件侵权行为的连带责任。故此,如果您发现本网站的内容侵犯了您的版权,请您的相关内容发至此邮箱【qin@198bona.com 】,我们在确认后,会立即删除,保证您的版权。