后端架构高可用可伸缩

-- 文章开始 --

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

一、入口层高可用

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自动故障转移

-- 完 --

本文分享自微信公众号 - java思维导图(java-mindmap)

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2018-05-14

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏黑白安全

信息搜集阶段可快速getshell的一些方式

2、各远程执行类漏洞,如,Struts2,iis,tomcat,proftp,elasticsearch...

17230
来自专栏蘑菇先生的技术笔记

Redis高可用分布式内部交流(九)

37970
来自专栏FreeBuf

技术分享 | 劫持DNS通过流量植入木马实验

很多时候对目标进行渗透时一般会从web、网络设备、针对性钓鱼这三个方向入手。假设我们控制了目标网络中的一台网络设备,如路由器,内网用户流量会从这个地方经过我们怎...

29530
来自专栏数据和云

墨菲定律:一个参数Drop_caches导致集群数据库实例崩溃

李真旭@killdb Oracle ACE,云和恩墨技术专家 个人博客:www.killdb.com 在墨菲定律里,我们知道,有可能发生的故障就一定会发生,哪怕...

33670
来自专栏腾讯云服务器团队的专栏

腾讯云 CBS 性能测试用例参考

2、fio测试建议在空闲的、未保存重要数据的硬盘上进行,并在测试完后重新制作文件系统。请不要在业务数据硬盘上测试,避免底层文件系统元数据损坏导致数据损坏。

631130
来自专栏优启梦

使用Referer Meta标签控制referer 来源

本文描述了一个关于 http 协议中 referer 的 metadata 参数的提议,使用这个 metadata 参数,html 文档可以控制 http 请求...

32650
来自专栏编程

自己打造Android Studio插件,提升开发效率

如果能够让重复工作变得自动化,比如我通过打造一个插件,提升了5%的工作效率。节省下来的时间,干点什么不好呢?

1.3K100
来自专栏大前端开发

从编程小白到全栈开发:从最容易的开始

学习编程,重要的一点就是要进行思考,而更重要的一点是进行动手实践。简单的代码逻辑,我们可能想想就能在脑子里建立出这个代码的样子来,但是别以为你能永远这样人肉运行...

11330
来自专栏公有云大数据平台弹性 MapReduce

简单了解公平调度器的一些队列设置

在腾讯云EMR的用户日常反馈中,经常会遇到因为YARN的队列配置不合理导致资源利用率不高,任务提交不上的问题,所以有了以下的文章,方便用户在日常按照一定的需求将...

26820
来自专栏同步博客

PHP将数据导出Excel表中(投机型)

  因为ms word和excel的文档都支持html文本格式,因此我们可以基于这个原理采用html文本格式进行数据的输出。

14730

扫码关注云+社区

领取腾讯云代金券