高性能架构

上一篇文章初识架构让我们对架构设计的复杂度考虑有了一定了解,主要有个高可用高性能可扩展。但仅仅知道是不够用的,接下来,将从高性能来进行详细分享

1. 高性能数据库

从数据库分享高性能,主要是两个方面分别是:

1.1 读写分离

读写分离的主要原理是将读和写分散到不同的节点上

1.1.1 实现方式

数据库搭建主从模式,一主多从或一主一从。主服务器负责写, 从服务器负责读。从服务器通过复制的方式从主服务器同步数据。

在业务域实现分别有两种方式:

  1. 从代码层面实现。主要是代码封装,通过将读写请求分离出,请求不同的数据源
  2. 从中间件层实现。如:MysqlProxy等

1.1.2 带来的问题

读写分离将业务读写的压力分开,但是也带来了一些其他问题,如:

  1. 主从复制可能有延时,主从数据间数据不一致问题
  2. 将数据的读压力分散开,但是并没有减少数据库的写压力
  3. 为了区分度读写操作,需要引入中间件或对代码进行改造

1.2 分库分表

通常在数据表有压力的时候,我们会采取分库分表的策略,将数据分在不同的数据区域,减少数据存储压力。

1.2.1 分库

业务分库:按照业务模块将不同的数据存储到不同的数据库服务器

2.1.1 带来的d问题
  1. 事务问题: 多库间操作无法在一个事务内完成
  2. 成本问题:分库带来服务器数量增加,从而增加成本
  3. 数据查询带来复杂问题: 多库不利于 join()操作

1.2.2 分表

分表:单表存储数据过大时,需要对数据进行分表存储,放在不同的表中。分表又分为两种,分别是:垂直分表、水平分表。

垂直分表:把不常用的字段分出去。分表方式如:备注,内容等大字段

水平分表:对单表数据较大的进行分表。分表方式如: ID, 年月

1.2.2.1 分表策略

分表需要把数据分配到不同的表中,这就涉及到了表数据的分配算法。主要的分配算法有:

  1. 范围路由:如根据ID,1999999,10000009999999
  2. Hash路由:可以根据某些字段,进化hash计算,如 hash%表数。
  3. 配置路由:新建一张表,配置路由键与表之间的关系。如log_id,table_num两列。
1.2.2.2 带来的问题
  1. 数据表聚合操作标的麻烦,如:group by,count等
  2. 合适的数据路由策略选择,防止数据不均匀

1.3 优化策略

通常,我们在数据库出现瓶颈压力的时候可能优先考虑的是上述方案,这样其实是不对的。对于数据库方面的优化策略主要是:1、从硬件方面优化。2、SQL优化。3、增加缓存。4、分库分表。这样优化的如要目的主要是减少代码的改动量,保证业务的稳定性。

2. 高性能NoSQL

在某些情况下,我们需要根据具体情况选择合适的NoSQL,具体有如下NoSQL。

2.1 Key-Value形式

key-value形式的NoSQL主要解决关系型数据库无法存储数据结构的问题。以Redis为代表。

2.2 文档数据库

文档数据库主要解决关系型数据库强Schema问题。以MongoDB为代表。

2.2.1 优点 & 缺点

优点:1、新增字段简单。 2、对历史数据不会造成影响。 3、容易存储复杂结构数据,如JSON。

缺点:1、不支持ACID

2.3 列式数据库

列式数据库主要解决大数据场景下I/O问题。以HBase,clickhouse为代表

2.3.1 优点 & 缺点

优点:1、数据读取量小,如一行是4K, 某列可能只有4Byte,可以减少I/O。 2、同一列数据高度相似,可以提高压缩比例,易于存储。

缺点:1、对多列数据进行修改,查询多列由于是随机I/O,相对与行顺序I/O,性能较差。

2.4 全文搜索引擎

全文搜索引擎主要解决关系型数据库全文搜索性能问题。以ES为代表。

1 & 2 小结

关于数据库选择方式,我们需要以需求为导向。根据合适的业务场景选择合适的数据库。主要的考量指标有:数据量、并发量、一致性要求、读写分布、安全、运维等。

3. 高性能缓存架构

在应对一些又计算后得出的数据,或者读多写少的场景,一般存储系统无法应对,我们需要引入缓存。如:Redis,MemCache。接下来主要说一下系统引入缓存架构带来的问题。

3.1 缓存穿透

缓存穿透主要是数据的查询直接落在数据库上导致。造成缓存穿透的主要原因有两点,分别是:

  1. 查询数据不存在。
  2. 查询数据刚好失效,生成缓存时间较长。

解决策略:

  1. 缓存空数据
  2. 使用布隆过滤器

3.2 缓存雪崩

缓存雪崩主要是缓存失效,引起系统性能急剧下降。造成雪崩的主要原因是:

  1. 新缓存生成耗费时间,多线程同时更新缓存,造成DB压力,从而拖动系统西能。

解决策略:

  1. 更新锁机制:对缓存的更新进行加锁操作。
  2. 后台更新机制: 缓存长久有效,通过后台手动更新或缓存失效,触发后台更新等。

3.3 缓存热点

缓存热点主要是同一时间访问量急剧增大导致,如微博上"爆"点。

解决策略:

  1. 多级缓存:通过实时分析,将预热数据存入本地缓存中,然后才是缓存系统
  2. 将热点数据进行多副本保存:如key_1, key_2, key..n等,分散查询。

4. 单机高性能

增加单机高性能,则可以通过增加进程或线程的方式,我们一般通过增加线程的方式。主要的方式有两种:分别是:

  1. IO多路复用, Reactor
  2. AIO

5. 高性能负载均衡

通常,负载均衡也是高性能的一块,一个合适的负载均衡,对系统的提升也非常明显。从大往小了说,主要分为三类,分别是:DNS负载,硬件负载,软件负载。接下来将一一介绍。

5.1 DNS负载均衡

DNS负载均衡主要是有DNS厂商提供的一种负载均衡算法,其主要逻辑是:通过解析域名,可以返回不同的IP地址。如:解析www.jd.com,上海用户通过DNS解析出来的地址可能是:10.23.12.1; 黑龙江用户解析出来的是:60.111.23.55;这样通过不同的IP,访问就近的地址,加速用户的访问。

5.1.1 优点 & 缺点

DNS负载的优点主要有:1、直接又DNS厂商提供,操作简单,成本低。2、用户访问就近区域,加速用户访问速度。

缺点也比较明细:1、IP缓存时间长,用户可能更新不及时。

5.2 硬件负载均衡

硬件负载均衡主要是通过硬件层面来进行负载均衡,和交换机,路由器类似。主要代表有F5,A10。

5.2.1 优点 & 缺点

优点:1、性能强劲,可以支持百万级并发量。 2、支持在网络各层级进行负载,支持多种负载算法。3、支持安全防火。如:DDOS

缺点:1、价格昂贵,一般公司承受不起。2、可以根据业务配置,但是无法进行扩展和定制

5.3 软件负载均衡

软件负载均衡主要是通过软件来进行负载均衡,主要代表有Nginx(7层)、LVS(4层)等。同硬件想比,软件则无法支持那么大的并发量。但也有自己的优点。

5.3.1 优点 & 缺点

优点:1、部署运维简单,都提供部署方法。2、便宜,多加机器就可以部署。3、灵活,可以在网络7层或4层进行配置,支持扩展。

缺点:1、没有硬件负载那么大并发,如Nginx并发:5W/s。2、不支持网络安全防护,如DDOS攻击。

5.4 负载均衡算法分类

讲完了负载均衡,那接下来就讲解一下负载均衡算法的分类,主要也分为四大类,分别是:任务平分类、负载均衡类、Hash算法、性能最优类。接下来一一分析一下。

5.4.1 任务评分类

任务平分类主要是将任务平均分配,实现比较简单,无状态,和机器无关。如:轮询

5.4.2 负载均衡类

这里的负载均衡不是我们理解的负载均衡,而是通过计算出机器的性能,使用情况,如:CPU,IO,网卡连接数等,然后在分配任务。对机器性能做出平衡。防止差的机器接收大量的任务。如:加权轮询,负载最低优先

5.4.3 Hash类

负载均衡根据任务中的某些信息,进行hash计算,将相同hash值的任务放在同一个服务器上。这样可以满足某些特定业务需求。如:根据机器Ip进行hash计算,或者根据id进行hash计算。

5.4.4 性能最优类

性能最优类和负载均衡类有所不同,性能最优类是站在客户端的角度来看,谁处理任务快,就把任务多分配一些。负载均衡类是站在服务器端的角度来看。

6 总结

以上是总结的关于高性能架构设计时,我们可以考虑的点。在考虑设计时,我们不必拘泥于选择其中一点,而是进行搭配使用。为了满足业务需求,进行最大程度选择组合,这样才可以设计出符合业务的高性能架构。

高性能架构

上一篇:硬链接和软链接


下一篇:JVM-字节码