web 服务器提供几个接口给客户进行调用,然后,我这边需要统计每个接口的调用次数,并记录每次处理后的结果,哪个客户调用的。
目前有两个做法:
直接在接口处理完业务逻辑之后,直接生成一条数据,插入到对应表中。这样每调用一次都需要插入一条数据。调用次数很频繁的情况下,会不会影响性能?
对于接口调用次数频繁的情况下,目前采用把统计数据,push 到任务队列里,然后另外启动 worker 定时去存放这些统计数据。(目前采用 celery 或者 rq )但是这样又有一个问题,每次运行 worker 的时候,只能处理一条数据,于是,我在 worker 中想把每条统计数据再次存放到 redis 队列中,然后每次都去查询 reids 相关队列中的长度,等到长度达到一定长度,再做批量插入。
在类似 celery,rq 任务队列中,传递图片数据是怎么处理的?直接传递图片 base64 之后的数据?还是传递地址,然后 worker 去下载再处理?
能说说这两种方法的优缺点吗?还有其他更好的方法吗?
PS:本身提供的服务中业务逻辑不需要有数据库相关的操作包括(增删改查)
感谢!!
1
kslr 2018-09-16 14:19:26 +08:00 via Android
首先看你的规模,大部分都可以直接怼
第二可以批量获取,第三还是看规模以及文件系统设计和文件类型 初步考虑存储文件而不是编码,这样灵活度更大一点 |
2
kslr 2018-09-16 14:21:37 +08:00 via Android
Celery Rabbitnq 完全是两个级别的工具,如果你一天只有几十万硬怼毫无问题
|
3
kslr 2018-09-16 14:22:23 +08:00 via Android
不过也看请求分布时间段是否集中,总之是完全看业务的
|
4
DCjanus 2018-09-16 14:26:32 +08:00 via Android
直接插表理论上影响不是很大,纯日志类的表没有太多冲突、计算、iO,直接插就好了,除非你量大的超出常规。
|
5
DCjanus 2018-09-16 14:35:00 +08:00 via Android
数据库负担大的扛不住再考虑消息队列削峰填谷,一条条写都扛不住再考虑写合并,要是连写合并都扛不住,你就该考虑分布式日志系统了。
但我觉得直接写数据库就能满足你需求了,先做个最简单的然后三倍日常峰值负载测试一下,满足需求就好了,折腾太多徒增烦恼。 |