RocksDB

转载:http://mp.weixin.qq.com/s?__biz=MzAwMDU1MTE1OQ==&mid=210272034&idx=1&sn=3be9d2b53c7fec88716ee8affd2515f8&scene=5&srcid=FtID3LDZmQvJW8mQ86jr#rd

多机房多活
对于我们这种核心系统,我们需要考虑多机房多活的问题。目前是应用无状态,通过在配置文件中配置各自机房的数据集群来完成数据读取。
wKioL1Xk-XbggTNSAAFYQ41tOTE135.jpg其实我们系统只要存储多机房就多活了,因为系统天然就是。数据集群采用一主三从结构,防止当一个机房挂了,另一个机房压力大产生抖动。
wKiom1Xk92HTR_anAAGJsr882SA865.jpg各个机房都是读本机房的从另外每个机房都是俩份数据,不怕因为机房突然中断恢复后的影响。


多种压测方案
我们在验证系统时需要进行压测。
线下压测,Apache ab,Apache Jmeter,这种方式是固定url压测,一般通过访问日志收集一些url进行压测,可以简单压测单机峰值吞吐量,但是不能作为最终的压测结果,因为这种压测会存在热点问题;


线上压测,可以使用Tcpcopy直接把线上流量导入到压测服务器,这种方式可以压测出机器的性能,而且可以把流量放大,也可以使用Nginx+Lua协程机制把流量分发到多台压测服务器,或者直接在页面埋点,让用户压测,此种压测方式可以不给用户返回内容。服务刚开始的时候大量使用tcpcopy做验证,对于一些新服务,如果无法使用tcpcopy我们就在页面埋url让用户来压。


另外压测时,要考虑读、写、读或写同时压。只压某一种场景可能都会不真实。


遇到的一些问题和解决方案

SSD性能差

使用SSD做KV存储时发现磁盘IO非常低。配置成RAID10的性能只有36MB/s;配置成RAID0的性能有130MB/s,系统中没有发现CPU,MEM,中断等瓶颈。一台服务器从RAID1改成RAID0后,性能只有~60MB/s。这说明我们用的SSD盘性能不稳定。


据以上现象,初步怀疑以下几点:SSD盘,线上系统用的三星840Pro是消费级硬盘;RAID卡设置,Write back和Write through策略(后来测试验证,有影响,但不是关键);RAID卡类型,线上系统用的是LSI 2008,比较陈旧。


下面是使用dd做的简单测试。
wKioL1Xk-j_Dg_QpAAFPA-F3Dc4997.jpg我们现实竟然使用的是民用级盘, 一个月坏几块很正常。后来我们全部申请换成了INTEL企业级盘,线上用3500型号。


键值存储选型压测

在系统设计初期最头痛的就是存储选型,我们对于存储选型时尝试过LevelDB、RocksDB、BeansDB、LMDB、Riak等,最终根据我们的需求选择了LMDB。


机器:2台
配置:32核CPU、32GB内存、SSD((512GB)三星840Pro—> (600GB)Intel 3500 /Intel S3610)
数据:1.7亿数据(800多G数据)、大小5~30KB左右
KV存储引擎:LevelDB、RocksDB、LMDB,每台启动2个实例
压测工具:tcpcopy直接线上导流
压测用例:随机写+随机读


LevelDB压测时,随机读+随机写会产生抖动(我们的数据出自自己的监控平台,分钟级采样)。
wKiom1Xk-DvjI06WAAJl2Qgltvk163.jpg我们线上一些顺序写的服务在使用leveldb,RocksDB是改造自LevelDB,对SSD做了优化,我们压测时单独写或读,性能非常好,但是读写混合时就会因为归并产生抖动。
wKioL1Xk-mfxv2tEAAI9GvGKg5A369.jpg在归并时基本达到了我们磁盘的瓶颈,LMDB引擎没有大的抖动,基本满足我们的需求。
wKiom1Xk-G_AZ8NIAAGvV9sI9k0303.jpg我们目前一些线上服务器使用的是LMDB,新机房正在尝试公司自主研发的CycleDB引擎。目前我看到的应该很少使用LMDB引擎的。


数据量大时Jimdb同步不动

Jimdb数据同步时要dump数据,SSD盘容量用了50%以上,dump到同一块磁盘容量不足。
解决方案:

  1. 一台物理机挂2块SSD(512GB),单挂raid0;启动8个jimdb实例;这样每实例差不多125GB左右;目前是挂4块,raid0;新机房计划8块raid10;

  2. 目前是千兆网卡同步,同步峰值在100MB/s左右;

  3. dump和sync数据时是顺序读写,因此挂一块SAS盘专门来同步数据;

  4. 使用文件锁保证一台物理机多个实例同时只有一个dump;

  5. 后续计划改造为直接内存转发而不做dump。


切换主从

因为是基于Redis的,目前是先做数据RDB dump然后同步。后续计划改造为直接内存复制,之前存储架构是一主二从(主机房一主一从,备机房一从)切换到备机房时,只有一个主服务,读写压力大时有抖动,因此我们改造为之前架构图中的一主三从。


分片配置

之前的架构是存储集群的分片逻辑分散到多个子系统的配置文件中,切换时需要操作很多系统。

解决方案:

  1. 引入Twemproxy中间件,我们使用本地部署的Twemproxy来维护分片逻辑;

  2. 使用自动部署系统推送配置和重启应用,重启之前暂停mq消费保证数据一致性;

  3. 用unix domain socket减少连接数和端口占用不释放启动不了服务的问题。


我们都是在应用本地部署的Twemproxy,然后通过中间系统对外提供数据。


模板元数据存储HTML

我们前端应用使用的是Nginx+Lua,起初不确定Lua做逻辑和渲染模板性能如何,就尽量减少for、if/else之类的逻辑;通过java worker组装html片段存储到jimdb,html片段会存储诸多问题,假设未来变了也是需要全量刷出的,因此存储的内容最好就是元数据。


因此通过线上不断压测,最终jimdb只存储元数据,lua做逻辑和渲染;逻辑代码在3000行以上;模板代码1500行以上,其中大量for、if/else,目前渲染性可以接受。


线上真实流量,整体性能从TOP99 53ms降到32ms。
wKioL1Xk_AKRhGDfAAFywdi89_U229.jpg绑定8 CPU测试的,渲染模板的性能可以接受。


wKiom1Xk-fGC1uZpAAECbOoXa4Q876.jpg

库存接口访问量600W/分钟

商品详情页库存接口2014年被恶意刷,每分钟超过600w访问量,tomcat机器只能定时重启;因为是详情页展示的数据,缓存几秒钟是可以接受的,因此开启nginx proxy cache来解决该问题,开启后降到正常水平;我们目前正在使用Nginx+Lua架构改造服务,数据过滤、URL重写等在Nginx层完成,通过URL重写+一致性哈希负载均衡,不怕随机URL,一些服务提升了10%+的缓存命中率。


目前我们大量使用内存级nginx proxy cache和nginx共享字典做数据缓存。
http://c.3.cn/recommend?callback=jQuery4132621&methods=accessories%2Csuit&p=103003&sku=1217499&cat=9987%2C653%2C655&lid=1&uuid=1156941855&pin=zhangkaitao1987&ck=pin%2CipLocation%2Catw%2Caview&lim=6&cuuid=1156941855&csid=122270672.4.1156941855%7C91.1440679162&c1=9987&c2=653&c3=655&_=1440679196326

还有我们会对这些前端的url进行重写,所以不管怎么加随机数,都不会影响我们服务端的命中率,我们服务端做了参数的重新拼装和验证。


微信接口调用量暴增

14年的一段时间微信接口调用量暴增,通过访问日志发现某IP频繁抓取;而且按照商品编号遍历,但是会有一些不存在的编号。

解决方案:

  1. 读取KV存储的部分不限流;

  2. 回源到服务接口的进行请求限流,保证服务质量。

  3. 回源到DB的或者依赖系统的,我们也只能通过限流保证服务质量。


开启Nginx Proxy Cache性能不升反降

开启Nginx Proxy Cache后,性能下降,而且过一段内存使用率到达98%。

解决方案:

  1. 对于内存占用率高的问题是内核问题,内核使用LRU机制,本身不是问题,不过可以通过修改内核参数
    sysctl -w vm.extra_free_kbytes=6436787
    sysctl -w vm.vfs_cache_pressure=10000

  2. 使用Proxy Cache在机械盘上性能差可以通过tmpfs缓存或nginx共享字典缓存元数据,或者使用SSD,我们目前使用内存文件系统。


配送至读服务因依赖太多,响应时间偏慢

配送至服务每天有数十亿调用量,响应时间偏慢。
解决方案:

  1. 串行获取变并发获取,这样一些服务可以并发调用,在我们某个系统中能提升一倍多的性能,从原来TP99差不多1s降到500ms以下;

  2. 预取依赖数据回传,这种机制还一个好处,比如我们依赖三个下游服务,而这三个服务都需要商品数据,那么我们可以在当前服务中取数据,然后回传给他们,这样可以减少下游系统的商品服务调用量,如果没有传,那么下游服务再自己查一下。


假设一个读服务是需要如下数据:

  1. 数据A 10ms

  2. 数据B 15ms

  3. 数据C  20ms

  4. 数据D  5ms

  5. 数据E  10ms


那么如果串行获取那么需要:60ms;而如果数据C依赖数据A和数据B、数据D谁也不依赖、数据E依赖数据C;那么我们可以这样子来获取数据:
wKioL1Xk_C2xAw7bAABrY2nc-pE641.jpg

那么如果并发化获取那么需要:30ms;能提升一倍的性能。


假设数据E还依赖数据F(5ms),而数据F是在数据E服务中获取的,此时就可以考虑在此服务中在取数据A/B/D时预取数据F,那么整体性能就变为了:25ms。


我们目前大量使用并发获取和预取数据,通过这种优化我们服务提升了差不多10ms性能。 而且能显著减少一些依赖服务的重复调用,给他们减流。
wKiom1Xk-h7h4QWoAAEkfMJDJ4k187.jpg如下服务是在抖动时的性能,老服务TOP99 211ms,新服务118ms,此处我们主要就是并发调用+超时时间限制,超时直接降级。
wKioL1Xk_FWhgkzjAAD5SNMMgjY960.jpg


网络抖动时,返回502错误

Twemproxy配置的timeout时间太长,之前设置为5s,而且没有分别针对连接、读、写设置超时。后来我们减少超时时间,内网设置在150ms以内,当超时时访问动态服务。对于读服务的话,应该设置合理的超时时间,比如超时了直接降级。



机器流量太大

2014年双11期间,服务器网卡流量到了400Mbps,CPU30%左右。原因是我们所有压缩都在接入层完成,因此接入层不再传入相关请求头到应用,随着流量的增大,接入层压力过大,因此我们把压缩下方到各个业务应用,添加了相应的请求头,Nginx GZIP压缩级别在2~4吞吐量最高;应用服务器流量降了差不多5倍;目前正常情况CPU在4%以下。


因为之前压缩都是接入层做的,后来因为接入的服务太多,因此我们决定在各应用去做。
wKiom1Xk-k6jgRuJAAC6dpsdO8o288.jpg

一些总结

  • 数据闭环

  • 数据维度化

  • 拆分系统

  • Worker无状态化+任务化

  • 异步化+并发化

  • 多级缓存化

  • 动态化

  • 弹性化

  • 降级开关

  • 多机房多活

  • 多种压测方案

  • Nginx接入层线上灰度引流

  • 接入层转发时只保留有用请求头

  • 使用不需要cookie的无状态域名(如c.3.cn),减少入口带宽

  • Nginx Proxy Cache只缓存有效数据,如托底数据不缓存

  • 使用非阻塞锁应对local cache失效时突发请求到后端应用(lua-resty-lock/proxy_cache_lock)

  • 使用Twemproxy减少Redis连接数

  • 使用unix domain socket套接字减少本机TCP连接数

  • 设置合理的超时时间(连接、读、写)

  • 使用长连接减少内部服务的连接数

  • 去数据库依赖(协调部门迁移数据库是很痛苦的,目前内部使用机房域名而不是ip),服务化

  • 客户端同域连接限制,进行域名分区:c0.3.cn c1.3.cn,如果未来支持HTTP/2.0的话,就不再适用了。


Q&A

Q1:对于依赖服务的波动,导致我们系统的不稳定,我们是怎么设计的?
我们的数据源有三套:前端数据集群 该数据每个机房有两套,目前两个机房。数据异构集群同上动态服务(调用依赖系统)。

  1. 设置好超时时间,尤其连接超时,内网我们一般100ms左右;

  2. 每个机房读从、如果从挂了降级读主;

  3. 如果前端集群挂了,我们会读取动态服务(1、先mget原子数据异构集群;2、失败了读依赖系统)。


Q2:静态化屏蔽通过js是怎么做的?

  1. 紧急上线js,做跳转;

  2. 上线走流程需要差不多10分钟,然后还有清理CDN缓存,用户端还有本地缓存无法清理;

  3. 我们目前文件都放到我们的自动部署上,出问题直接修改,然后同步上去,重启nginx搞定。


Q3:内网的服务通过什么方式提供?
我偏好使用HTTP,目前也在学习HTTP2.0,有一些服务使用我们自己开发类似于DUBBO的服务化框架,之前的版本就是DUBBO改造的。


Q4:对于mq 的处理如果出现异常是怎么发现和处理的?

  1. MQ,我们目前是接收下来存Redis,然后会写一份到本地磁盘文件;

  2. 我们会把消息存一天的;

  3. 一般出问题是投诉,我们会紧急回滚消息到一天中的某个时间点。


Q5:对于模板这块,有做预编译处理?或者直接使用Lua写模板吗?

  1. luajit,类似于java jit;

  2. lua直接写模板。


Q6: jimdb能否介绍下,特性是什么,为什么选用?

  1. jimdb就是我们起的一个名字,之前版本就是redis+lmdb持久化引擎,做了持久化;

  2. 我们根据当时的压测结果选择的,按照对比结果选择的,我们当时也测了豆瓣的beansdb,性能非常好,就是需要定期人工归并。


Q7:咨询下对于价格这类敏感数据,前端有缓存么?还是都靠价格服务扛?

  1. 价格前端不缓存;

  2. 价格实时同步到Nginx+Lua本地的redis集群(大内存);

  3. 不命中的才回源到tomcat查主redis/DB。

价格数据也是通过MQ得到变更存储到本地redis的,nginx+lua直接读本机redis,性能没的说。


Q8:库存和价格一样的模式处理吗?
前端展示库存不是,我们做了几秒的服务端缓存。


Q9:github里有一个开源的基于lmdb的redis 你们用的这个吗?
我们内部自己写的,有一版基于LevelDB的,我记得github上叫ardb。


Q10:看测试条件说测试的是大小5~30KB左右的数据,有没有测试过更大文件lmdb的表现?
这个没有,我们的数据都是真实数据,最大的有50KB左右的,但是分布比较均匀;当时还考虑压缩,但是发现没什么性能问题,就没有压缩做存储了。


Q11:关于redis缓存,是每个子系统拥有自己的一套缓存;还是使用统一的缓存服务?是否有进行过对比测试?(看到又说使用单机缓存防止服务挂掉,影响整体服务)

  1. 我们公司有统一的缓存服务接入并提供运维;

  2. 我们的服务自己运维,因为我们是多机房从,每机房读自己的从,目前不支持这种方式;

  3. (看到又说使用单机缓存防止服务挂掉,影响整体服务)这个主要是降级+备份+回源解决。


Q12: “我们目前一些线上服务器使用的是LMDB,其他一些正在尝试公司自主研发的CycleDB引擎”。 开始自主研发,这个是由于lmdb有坑还是处于别的考虑?

  1. 写放大问题;

  2. 挂主从需要dump整个文件进行同步。


想和群内专家继续交流电商高可用架构,请关注公众号后,回复arch,申请进群。


本文策划陈刚@北京智识,内容由刘世杰@猎聘网编辑,四正@大连华信校对与发布,其他多位志愿者对本文亦有贡献。更多关于架构方面的内容,读者可以通过搜索"ArchNotes"或点击页首的蓝字,关注"高可用架构"公众号,查看更多架构方面内容,获取通往架构师之路的宝贵经验。转载请注明来自"高可用架构 (ArchNotes)"微信公众号。


©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页