Python进阶 | 实时计算 | 如何从几百到几千再到几万吞吐量

前言

这次是慢查询的故事,一些情况下很难避免,我们屏蔽来源,只讨论量。从最开始只要简单处理能过滤报警(几百),坏个盘也就是这么量。到小 Region灰度,单Client 峰值8K,再到大集群单 Client 峰值几万,程序一路翻车。

对于报警而言,我们更关注各个来源每秒可以处理的量,总体意义不大,数据来源主要为双机压测结果(非Server吞吐量,且包含网络请求耗时)。

一些环境下是不存也不方便引入其他中间件的,一个Centos7 自带的 Python 2.7.5 一路黑到底。

项目不同阶段

日常需求阶段(几百)

慢查询有一定格式,我们简单抽象为 A 和 B,其中含义如下:

A:  检测到一个查询还没结束,无法判定,因此记录到日志中

B: 检测到一个很耗时的查询,并且已结束,记录到日志中

因此常见组合方式为:

  • AA...AB (多次受到慢查询存在告警,最后受到结束告警)
  • B (刚好检测到一个耗时的查询,并且已结束)
  • A...A (异常情况)

消息消费大致是B已完成,需要实时处理,A则需要抑制并判断阈值在报警,因此可以将服务分为 Server  和 Client:

Client 读取日志,记录 Offset,过滤无效日志,发送成功则刷新 Offset,否则暂停读取,重发。

Server则分为Master 和 Monitor,Master处理实时数据,其他的写入文件,完成就返回,剩下由有Monitor 消费,由此借助文件实现跨进程通信,以及消息实时落盘。(消息生成主键,因此重复写不影响,Monitor 读取时候直接去重即可。)

有很多成熟文件DB,简单的操作背后都是时延增大,本文是直接读写文件。因写文件而速成,也会因文件也受限。

多客户端冲突期

第一版有个很大的竞争点,就是所有消息公用一个文件作为跨进程通信与落盘。因此多客户端已接入,立马互相竞争文件锁,性能瞬间只剩几十,惨不忍睹。

提示:一个 Region 两台统计点,日志是随机打过去的,因此采用放在同一个文件进行比对。当然这是不合理的,当对同一个消息AB很短时间间隔内到达两个节点。再经过采集合并发送到报警服务器,基本无法保证有序。这个阶段已调整,单节点保序。

按 Client 分消息队列,就是分文件了,性能又恢复了。

小故障爆发期(几千,比如2-3千)

这个时候就是把以前偷的懒都给补上了,当然不是每个思路都有效,比较有效的有:

  • 各类批量操作: 批量写消息、批量查数据库等
  • 更换序列化,比如由 Json 改为 Marshal
  • 优化时间格式处理, 自带的 strptime 性能很差,可以小用 panda
  • cache,集群、节点等相关属性变化很低,适合放内存

 替换实现是一个系统活,有一些测压对比统计,可以供大家参考,真正有提升在替换。

内置

单条序列化长度

1K列表序列化长度

单条1W次

dum

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值