celery 处理结果的入库问题

2017-07-20 07:45:19 +08:00
 akmonde

鄙人做了一个小项目,部署了 celery 的分布式,本来结果是直接在节点往主控节点的 mysql 里面存入的。

问题来了,有 leader 表示这个不太安全,直接互联网上暴露了 mysql 接口,降权神马的也欠考虑。

另外,leader 觉得这个东西,一旦节点部署多了以后,主控端唯一的 mysql 会负荷不了高速大量的数据写入。 所以他建议我找几台能缓冲的中间节点,借助上面的某种机制来存入 mysql,而不是将 mysql 接口直接暴露给 celery 的节点。 同时,这样有缓冲,数据库写入的稳定性也能得到保证。

鄙人水平有限,是野路子 coder,所以没有想到特别好的法子,求大家指点下迷津。

在线等,很急,leader 这两天在催我要方案。 感谢!!!

PS:感觉这个应该经验丰富些的大佬都能帮我解答的,这帖子不能跟以前似的沉了吧。。

4160 次点击
所在节点    Python
18 条回复
akmonde
2017-07-20 07:49:01 +08:00
这里怕大家没看懂,故此补充下,我这边是跟大家求方案细节,我才好去做计划。
如果有大佬做过或者有过完善点的想法,劳烦多敲几个字指点下小弟,感谢感谢!
cszeus
2017-07-20 07:59:55 +08:00
小项目确定真的有“高速大量”的数据写入么?不如先看看 mysql 到底能不能承受吧。
NoBeeBee
2017-07-20 09:54:04 +08:00
首先有个小问题,为神马说“直接互联网上暴露了 mysql 接口” 。难道你的 web 应用框架,是直接把后台处理数据库部分代码直接暴露在 web 访问的表层了?我记得 Django 一类的 web 框架都有很好的分层处理的概念吧,譬如 mvc 等。
CryMeatel
2017-07-20 11:47:03 +08:00
……数据写入 QPS 是多少…… 得根据具体业务量看是否需要优化~“提前优化是万恶之源”
iConnect
2017-07-20 12:09:00 +08:00
小项目就要上 celery 分布式,这确定有必要吗?
iwishing
2017-07-20 12:29:48 +08:00
celery 不是往 broker 发消息的吗?写个代理把 broker 里面的结果存到 MySQL 就好了吧
juntao
2017-07-20 13:44:02 +08:00
不知道具体业务如何。根据你的描述
1 分理一个写数据库的 task
2 这个 task 只允许在主节点跑

上面可以解决不暴露 mysql 给其他 celery node 这个目标。
另外 celery 是基于消息队列的,这本身就是你写 mysql 的缓冲。
wizardoz
2017-07-20 13:50:40 +08:00
直接互联网上暴露了 mysql 接口
=====================
这个问题有很多简单的方式可以解决
KgM4gLtF0shViDH3
2017-07-20 14:52:18 +08:00
为什么会暴露 MySQL 接口啊求教
akmonde
2017-07-20 16:01:15 +08:00
@cszeus @CryMeatel @iConnect 项目是小,但类似于分布式采集数据类的东西,每个任务都会有写入数据的操作,所以一旦节点多了以后,不做写入缓冲,确实可能存在数据写入过量。
akmonde
2017-07-20 16:06:38 +08:00
@NoBeeBee @bestkayle leader 的意思是,既然是分布式的,那每个节点我都需要配置 mysql 连接信息,既然部署到公网,无论是传输途中,还是节点服务器被黑,都是有可能泄露主控端的数据的。
@wizardoz 大佬,求教如何解决,随便甩给小弟几个方案就成^_^。
@juntao @iwishing 小弟看看怎么方便实施,先感谢下~
xdays
2017-07-20 17:01:36 +08:00
celery worker 作为 producer 丢结果到 queue 里,然后 mysql 那一头作为 consumer 处理结果入库。
whnzy
2017-07-20 17:26:24 +08:00
既然有 leader 为什么不问他。。。。
carilove
2017-07-20 17:33:25 +08:00
部署到公网,这个题无解
MySQL 有暴露的风险,你的 celery broker 一样会暴露,而且 broker 的信息一样是全的
wizardoz
2017-07-20 21:13:03 +08:00
@akmonde 方案 1 服务器之间建立 VPN 连接,MySQL 服务配置只接受来自 VPN 内网 IP 的连接。用 VPN 的验证机制来保证安全。当然,VPN 可能网络稳定性会是个问题。 方案 2 配置 MySQL 主机的 iptables,使之对 3306 端口只放行来自特定 IP 的连接。
当然我说的两种方案可能都有弊端。但是我想表达的意思是,安全问题可以找一些成熟的工具来解决而不是因为顾虑安全问题而放弃高效的工具。
akmonde
2017-07-20 21:52:27 +08:00
@xdays 您的意思还是将 mysql 处理这块作为节点吧?
@whnzy leader 不是做开发的。
@carilove 不会啊,为了避免 broker 量过载,我那边计划的是跑完一批任务,就清空一次,不然肯定占用太多了。
@wizardoz 大佬说的蛮对的,个人觉得即使做缓冲也无法解决安全问题,确实需要第三方进行加固。
hanssx
2019-09-02 14:45:58 +08:00
考虑做成 RPC ?
akmonde
2019-09-02 21:13:26 +08:00
@hanssx 可以考虑,我试试,本来是做的服务集群,谢谢指点~

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/376562

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX