• 近期将进行后台系统升级,如有访问不畅,请稍后再试!
  • 极客文库-知识库上线!
  • 极客文库小编@勤劳的小蚂蚁,为您推荐每日资讯,欢迎关注!
  • 每日更新优质编程文章!
  • 更多功能模块开发中。。。

后端架构高可用可伸缩

 
下面来分层介绍实践方法。

一、入口层高可用

nigix 两个 keeplive 保活 心跳做好。
  • 使用心跳技术:keeplive 提供这个技术
  • 比如机器 A IP 是 1.2.3.4,机器 B IP 是 1.2.3.5,那么再申请一个 IP (1.2.3.6)我们称之为心跳 IP,平时绑定再 A 上面,如果 A 宕机,那么 IP 会自动绑定到 B 上面
  • DNS 层面绑定到心跳 IP 即可
  • 两台机器必须在同一网段
  • 服务监听必须监听所有 IP,如果仅仅监听心跳 IP,那么从机上的服务(不持有心跳 IP 的机器)会启动失败
  • 服务器利用率下降(混合部署可以改善这一点)
考虑一个问题,两台机器,两个公网 IP,DNS 把域名同时定位到两个 IP,这算高可用吗
不算,客户端(比如浏览器) 解析完后会随机选一个 IP 访问 , 而不是一个失败后就去另一个 。 所以如果一台机器当机 ,那么就有一半左右的用户无法访问 。

二、业务层高可用

  • 业务层不要有状态 , 状态分散到缓存层和数据库层 。 只要没有状态,业务层的服务死掉后,前面的 nginx 会自动把流量打到剩下的服务 。 所以,业务层无状态是一个重点。
  • 友情提醒:不要因为想让服务无状态就直接用 cookie session, 里边的坑有点大,考察清楚后再用比较好。比如重放攻击 。

三、缓存层高可用

  • 缓存层分得细一点,保证单台缓存宕机后数据库还能撑得住 。
  • 中小模下缓存层和业务层可以混合部署, 这样可以节省机器
  • 大型规模网站,业务层和缓存层分开部署。
  • 缓存层高可用,缓存可以启用主从两台,主缓存活着的时候,主缓存读,主从缓存都写,主缓存宕机后,从变主,主恢复后, 变成新的从。这样可以保证数据完整性,实现高可用

四、数据库高可用

  • MySQL 有主从模式, 还有主主模式都能满足你的需求
  • MongoDB 也有 ReplicaSet 的概念,基本都能满足大家的需求。

高可用小结

五、入口层可伸缩

  • 入囗层如何提供伸缩性?直接铺机器 ?然后 DNS 加 IP 就可以了吧?
  • 可以,但也有需要注意的地方
  • 尽管一个域名解析到几十个 IP 没有问题,但是很浏览器客户端只会使用前面几个 IP,部分域名供应商对此有优化(比如每次返回的 IP 顺序随机 ), 但是这个优化效果不稳定。推荐的做法是使用少量的 nginx 机 器作为入囗,业务服务器隐藏在内网(HTTP 类型的业务这种方式居多)

六、业务层可伸缩

  • 跟应付高可用一样,保证无状态是很好的手段。加机器继续水平部署即可。

七、缓存层可伸缩

  • 直接用 codis 或者 redis 3.0 即可
  • 如果低峰期间数据库能抗的住 ,那么直接下线存然后上新缓存就是最简单有效的办法
缓存类型 
  • 强一致性缓存: 无法接受从缓存中读取错误的数据(比如用户余额)
  • 弱一致性缓存:可以接受一段时间内的错误数据,例如微博转发数
  • 不变型缓存:缓存 key 对应的 value 不会变更
    弱一致性和不变型缓存扩容很方便,用一致性 HASH 即可

    一致性 HASH

    在分布式集群中,对机器的添加删除,或者机器故障后自动脱离集群这些操作是分布式集群管理最基本的功能。如果采用常用的 hash(object)%N 算法,那么在有机器添加或者删除后,很多原有的数据就无法找到了,这样严重的违反了单调性原则
    一致性 HASH 可以有效解决这个问题,一致性哈希算法在保持了单调性的同时,还是数据的迁移达到了最小,这样的算法对分布式集群来说是非常合适的,避免了大量数据迁移,减小了服务器的的压力。
    举个例子
    如果缓存从 9 台扩容到 10 台, 简单 Hash 况下 90%的缓存会马上失效,而一致性 Hash 情况下,只有 10%的缓存会失效。

强一致缓存问题

  • 1.缓存客户端的配置更新时间会有微小的差异,在这个时间窗内有可能会拿到过期的数据。
  • 2.如果在扩充节点之后裁撤节点,会拿到脏数据。比如 a 这个 key 之前在机器 1, 扩容后在机器 2,数据更新了, 但裁撤节点后 key 回到机器 1 这样就会有脏数据的问题
问题二解决方法:要么保持永不减少节点,要么节点调整间隔大于数据有效时间。
问题一解决方法:
  – 两套 hash 配置都更新到客户端,但仍使用旧的配置
  – 两个个客户端改为只有两套 hash 结果一致的情况下会使用缓存,其余情况从数据库读,但写入缓存。
  –  逐个客户端通知使用新配置。

八、数据库可伸缩

  • 水平拆分
  • 垂直拆分
  • 定期滚动
九、总结
高可用 HA(High Availability)是分布式系统架构设计中必须考虑的因素之一,它通常是指,通过设计减少系统不能提供服务的时间。
方法论上,高可用是通过冗余+自动故障转移来实现的。
整个互联网分层系统架构的高可用,又是通过每一层的冗余+自动故障转移来综合实现的,具体的:
(1)【客户端层】到【反向代理层】的高可用,是通过反向代理层的冗余实现的,常见实践是 keepalived + virtual IP 自动故障转移
(2)【反向代理层】到【站点层】的高可用,是通过站点层的冗余实现的,常见实践是 nginx 与 web-server 之间的存活性探测与自动故障转移
(3)【站点层】到【服务层】的高可用,是通过服务层的冗余实现的,常见实践是通过 service-connection-pool 来保证自动故障转移
(4)【服务层】到【缓存层】的高可用,是通过缓存数据的冗余实现的,常见实践是缓存客户端双读双写,或者利用缓存集群的主从数据同步与 sentinel 保活与自动故障转移;更多的业务场景,对缓存没有高可用要求,可以使用缓存服务化来对调用方屏蔽底层复杂性
(5)【服务层】到【数据库“读”】的高可用,是通过读库的冗余实现的,常见实践是通过 db-connection-pool 来保证自动故障转移
(6)【服务层】到【数据库“写”】的高可用,是通过写库的冗余实现的,常见实践是 keepalived + virtual IP 自动故障转移


丨极客文库, 版权所有丨如未注明 , 均为原创丨
本网站采用知识共享署名-非商业性使用-相同方式共享 3.0 中国大陆许可协议进行授权
转载请注明原文链接:后端架构高可用可伸缩
喜欢 (0)
[247507792@qq.com]
分享 (0)
勤劳的小蚂蚁
关于作者:
温馨提示:本文来源于网络,转载文章皆标明了出处,如果您发现侵权文章,请及时向站长反馈删除。

欢迎 注册账号 登录 发表评论!

  • 精品技术教程
  • 编程资源分享
  • 问答交流社区
  • 极客文库知识库

客服QQ


QQ:2248886839


工作时间:09:00-23:00