主要是总结下本人在双11的druid.io集群运维工作和一些思考
直接画个图记忆下
问题总结
运维自动化?
不少问题还是通过告警,然后人工判断再操作
这里是可以自动化点的,判断的条件要抽象符合逻辑(机器指标没有就找运维,自身系统指标没有就开发,脚本能用就上起来),操作可以封装(有操作,有回退),就可以开工
需求反复/事后通?
总是在问题暴露的时候才去考虑如何解决,事实上之前就提过,就是不重视,以为问题不大或者不重要。
所以尽早的模拟,开始做,没有问题也要模拟问题,这跟写算法考虑边界情况差不多,要有先见之明
设计上和能力不够?
架构设计上是有缺陷的,再就是能力不够,想改改不了,得通过第三方或者继续深入研究,提高下能力,然后让架构更好点了
双11和平时的区别?
区别不大,因为事先做好了压测和扩容准备;不过凡事都有意外,就看考虑是否周全了,不周全也有临时补救措施,总是以造成最小影响为目的,作为一个考验服务能力的机会,也是暴露问题和改进的机会。
没什么特别区别要说的
druid.io表现总结
druid.io + tranquility 最怕的是两台middleManager的挂掉(宕机或者OutOfMemory),不过以这么久的运维经验来看,基本这种概率是很小的(机器同时宕机概率较小,除非停电或者机房怎么了,其次:middleManager足够且实时查询做了一些超大查询限制,同时任务有备份,和上游有lag告警之类的,告警是比较足够的)
整体大促期间任务方面很稳定,查询方面会上涨不少(不过查询路由,限流,机器实现扩容都是有的,机器各种监控都有,可随时扩的),查询也是稳的很;整体表现感觉可以打9分(满分10分),除去一些意外
- 预估不足导致临时扩容
实时任务流量上涨,那就扩,目前手工或者自动都行,有时间窗口和正确的预估基本提前解决了99%的实时任务。一台2C4G tranquility 消费上游1-3w qps可以,不过对于>=200w
qps的上游kafka实时流,确实会消耗很多的机器,同时kafka partition需要扩在合理范围,太小了消费也跟不上
不过总是会存在预估不足的时候,本次双11就遇到,不过告警的及时和操作的及时,临时扩容解决了
- 数据倾斜
这个常有的事情,继续扩可以解决,加随机维度也可以解决;危急情况,当然就是扩了再说,缓解下倾斜问题;不过后续还是要对数据进行分析/治理,避免严重的倾斜,现阶段倾斜已经hash了所有维度值,理论上是还好的,没有数量级别的倾斜,这一点后续可能要预判下,做好应对处理
个人操作总结
这次本人值班负责总结就是:同往常一样,千万不能乱,仍然是分析各种指标,定位到问题,然后合理操作,动作无非比平时快了点。
如平常一样,没必要慌慌张张的。
----------2020年11月20日 星期五 20时48分28秒 CST