六、遇到的一些坑和问题.pdfVIP

六、遇到的⼀些坑和问题 遇到的⼀些坑和问题 SSD性能差 键值存储选型压测 数据量⼤时JIMDB 同步不动 切换主从 分⽚配置 模板元数据存储HTML 存接⼜访问量600w/分钟 微信接⼜调⽤量暴增 开启Nginx Proxy Cache性能不升反降 配送⾄读服务因依赖太多，响应时间偏慢 ⽹络抖动时，返回502错误 机器流量太⼤ SSD性能差 使⽤SSD做K 存储时发现磁盘IO⾮常低。配置成RAID 10 的性能只有3~6MB/s ；配置 成RAID0 的性能有~ 130MB/s ，系统中没有发现CPU ，MEM ，中断等瓶颈。⼀台服务 器从RAID 1改成RAID0后，性能只有~60MB/s 。这说明我们⽤的SSD盘性能不稳定。 根据以上现象，初步怀疑以下⼏点：SSD盘，线上系统⽤的三星840Pro是消费级硬 盘。RAID卡设置，Write back和Write through策略。后来测试验证，有影响，但不是 关键。RAID卡类型，线上系统⽤的是LSI 2008 ，⽐较陈旧。 本实验使⽤dd顺序写操作简单测试，严格测试需要⽤FIO等⼯具。 键值存储选型压测 我们对于存储选型时尝试过LevelDB 、RocksDB 、BeansDB 、LMDB 、Riak等，最终根 据我们的需求选择了LMDB 。 机器：2 台 配置：32核CPU 、32GB 内存、SSD （(5 12GB)三星840Pro-- (600GB)Intel 3500 /Intel S3610 ） 数据：1.7亿数据 （800多G数据）、⼤⼩5~30KB左右 K 存储引擎：LevelDB 、RocksDB 、LMDB ，每台启动2个实例 压测⼯具：tcpcopy直接线上导流 压测⽤例：随机写+随机读 LevelDB压测时，随机读+随机写会产⽣抖动 （我们的数据出⾃⾃⼰的监控平台，分钟 级采样）。 RocksDB是改造⾃LevelDB ，对SSD做了优化，我们压测时单独写或读，性能⾮常 好，但是读写混合时就会因为归并产⽣抖动。 LMDB引擎没有⼤的抖动，基本满⾜我们的需求。 我们⽬前⼀些线上服务器使⽤的是LMDB ，其他⼀些正在尝试公司⾃主研发的 CycleDB引擎。 数据量⼤时JIMDB 同步不动 Jimdb数据同步时要dump数据，SSD盘容量⽤了50%以上，dump到同⼀块磁盘容量不 ⾜。解决⽅案： 1、⼀台物理机挂2块SSD(5 12GB) ，单挂raid0 ；启动8个jimdb实例；这样每实例差不多 125GB左右；⽬前是挂4块，raid0 ；新机房计划8块raid 10 ； 2、⽬前是千兆⽹卡同步，同步峰值在100MB/s左右； 3、dump和sync数据时是顺序读写，因此挂⼀块SAS盘专门来同步数据； 4 、使⽤⽂件锁保证⼀台物理机多个实例同时只有⼀个dump ； 5、后续计划改造为直接内存转发⽽不做dump 。 换主从 之前存储架构是⼀主⼆从 （主机房⼀主⼀从，备机房⼀从）切换到备机房时，只有⼀ 个主服务，读写压⼒⼤时有抖动，因此我们改造为之前架构图中的⼀主三从。 分⽚配置 之前的架构是分⽚逻辑分散到多个⼦系统的配置⽂件中，切换时需要操作很多系统； 解决⽅案： 1、引⼊Twemproxy 中间件，我们使⽤本地部署的Twemproxy来维护分⽚逻辑； 2、使⽤⾃动部署系统推送配置和重启应⽤，重启之前暂停mq消费保证数据⼀致性； 3、⽤unix domain socket减少连接数和端⼜占⽤不释放启动不了服务的问题。 模板元数据存储HTML 起初不确定Lua做逻辑和渲染模板性能如何，就尽量减少for 、if/else之类的逻辑；通过 j ava worker组装html⽚段存储到jimdb ，html⽚段会存储诸多问题，假设未来变了也是 需要全量刷出的，因此存储的内容最好就是元数据。因此通过线上不断压测，最终 jimdb只存储元数据，lua做逻辑和渲染；逻辑代码在3000⾏以上；模板代码1500⾏以 上，其中⼤量for 、if/else ，⽬前渲染性能可以接受。 线上真实流量，整体性能从TP99 53ms降到32ms 。 绑定8 CPU测试的，渲染模板的性能可以接受。 库存接⼜访问量600w/分钟 商品详情页 存接⼜20 14年被恶意刷，每分钟超过600w访问量，tomcat机器只能定时