用户您好!请先登录!

系统单点那点事

系统单点那点事

系统的单点问题是高可用性和高性能的主要屏障之一,在软件系统架构中,为什么会存在单点?

  • 无意为之:存在设计缺陷,出现了单点;
  • 有意为之:简化系统设计,设置单点;

典型互联网高可用架构,哪些地方可能存在潜在单点?

典型互联网高可用架构:

  • 客户端,通过DNS,由域名拿到nginx的外网IP;
  • 反向代理,nginx是后端入口;
  • 站点应用,典型的是tomcat或者apache;
  • 服务,典型的是dubbo提供RPC服务调用,或者其它的RPC调用框架
  • 数据层,典型的是读写分离的db架构;

在这个互联网架构中,站点、服务、数据库的从库都容易通过冗余的方式来保证高可用,但:

  • nginx是一个潜在的单点;
  • 数据库写库也是一个潜在的单点;

哪些例子,因为设计需要,有意设置的单点?

在诸多的互联网框架中,不管是哪一类基础应用,一般都会有一个所谓的 Master节点,用来控制和调度,非常类似通信协议中的控制层协议,而为了简化,这类Master节点通常都设计为单点。这里就面临两个大问题:

  • 高可用问题:单点一旦发生故障,服务就会受到影响;
  • 性能瓶颈:单点不具备良好的扩展性,单点的性能上限往往就是整个系统的性能上限;

“高可用”问题通常怎么优化?

shadow-master是一种很常见的解决单点高可用问题的技术方案。shadow-master,顾名思义,它只是单点master的一个shadow(影子):

  1. master工作时,shadow-master只备份;
  2. master出现故障时,shadow-master会自动变成master,继续提供服务;

shadow-master它能够解决高可用的问题,并且故障的转移是自动的,不需要人工介入,但不足是它使资源的利用率降为了50%,业内经常使用keepalived+vip的方式实现这类单点的高可用。

除了GFS与MapReduce系统中的主控master,nginx和数据库的主库master亦可用类似的方式来保证高可用:

  1. 两个主库设置相互同步的双主模式;
  2. 平时只有一个主库提供服务;
  3. 异常时,虚IP漂移到另一个主库,shadow-master变成主库继续提供服务;

“性能瓶颈”的单点问题通常怎么优化?

有时候,单点设计是有意为之,此时单点的性能(例如GFS中的master)有可能成为系统的瓶颈,那么,减少与单点的交互,便成了存在单点的系统优化的核心方向。如何来减少与单点的交互,有两种常见的方法:

  1. 批量写;
  2. 客户端缓存;

如何利用“批量写”减少与单点的交互,提升整体性能?(可以参见ID生成器的例子)

如何利用“客户端缓存”减少与单点的交互,提升整体性能?

这类缓存的命中非常非常高,在99%以上(因为文件的自动迁移是小概率事件),这样与master的交互次数就降低了100倍。

批量写,客户端缓存,对性能的提升也有极限,单点性能优化还有没有其他方法?

以nginx为例,如何来进行水平扩展呢?

通过DNS轮询,在DNS-server,一个域名可以配置多个IP,每次DNS解析请求,轮询返回不同的IP,就能实现nginx的水平扩展,扩充负载均衡层的整体性能。

数据库单点写库也是同样的道理,在数据量很大的情况下,可以通过水平拆分,来提升写入性能。

X-Eyes Admin
X-Eyes Admin

要发表评论,您必须先登录