写点什么

赵钟秋谈又拍网架构中的消息 / 任务系统

  • 2011-12-31
  • 本文字数:1812 字

    阅读完需:约 6 分钟

AI 大模型超全落地场景&金融应用实践,8 月 16 - 19 日 FCon x AICon 大会联诀来袭、干货翻倍!

赵钟秋,又拍网核心开发人员,关注多种计算机语言、Web 技术和开源技术。他在 QCon 杭州 2011 大会的开放平台专题做了名为《又拍网架构中的消息 / 任务系统》的讲座,并和参会者做了热烈的讨论。会后,InfoQ 中文站对赵钟秋做了采访。

InfoQ:又拍的图片云计算平台与一般的 CDN 有什么区别与优势?

又拍图片云计算平台是 Amazon S3 + CloudFront 模式,因为源数据机房包含在整个 CDN 系统中(一般 CDN 服务源服务器往往在客户各自的机房),所以网络优化更彻底,达到整个 CDN 最佳效果。并且面对国内各省市之间复杂的网络结构,可以不断调整优化最佳链路(一般 CDN 服务,回源链路一旦确定,很少会再去为客户做变动)。另外,又拍在提供文件存储加速外,利用公司本身图片方面的技术积累,还提供一些特色功能:比如针对图片文件类型生成缩略图的功能,在线管理功能,防盗链功能等等。

InfoQ:又拍从什么时候开始使用 Erlang,目前开发团队有多大规模,除了消息系统,Erlang 还用在什么地方?给又拍带来了什么优势?

又拍从 2010 年初开始使用 Erlang,我们并没有专门的 Erlang 开发团队(需要的时候由团队中 1-2 个人负责 Erlang 相关开发)。除了消息系统,我们的文件存储系统也是使用 Erlang 开发。我们喜欢用最合适、最方便的工具解决问题,我们认为目前在分布式系统的开发中,Erlang 就是这样的工具。Erlang 的引入也的确为又拍这样的小团队快速地开发高效的、稳固的分布式系统带来了可能性。

InfoQ:选用 RabbitMQ 的时候,与其它的消息系统比如 ZMQ 等等,怎么确定造型的呢,是否有实际的 Benchmark 例子?

选择 RabbitMQ 是 2009 年的事了,当时网站架构在做比较大的变迁。又拍原来的架构是基于 Java 的,那次的迁移是打算减轻对 Java 体系的依赖,而开源消息队列中比较有名的 Apache ActiveMQ 是基于 Java 的实现,显得太厚重,所以被排除在我们的考虑之外。另外,那个时候 ZMQ 还没推出。没有具体了解过 ZMQ,以目前地认识来看,我认为它们之间也存在很大的差异。例如 RabbitMQ 比较完整的实现了 AMQP 协议,而 ZMQ 则提供了简单的接口,相比之下,前者显然比后者偏重。如果是比较性能,ZMQ 会胜出是无庸置疑。后面我们会对 ZMQ 作进一步了解,因为它可能能和 YPTask 有一个很好的结合。目前我们也没有再使用 RabbitMQ。

InfoQ: YPTask 是在 RabbitMQ 上的包装吗?有哪些自己独特的地方,是否回馈开源社区?

YPTask 和 RabbitMQ 没有任何关系,实际上 YPTask 并不是消息系统,确切地讲应该是一个基于消息的远程方法调用系统。YPTask 是基于 Erlang 的 OTP 实现的,本身就是一个很健壮的分布式系统。它具备管理、配置外部工作进程的功能,而简化了消息队列地实现。外部工作进程不是通过网络接口与 YPTask 通信的,而是通过标准输入 / 输出。所以理论上后端的工作进程可以用任何语言实现,只要它支持 Erlang 的序列化方式 BERT。事实上,BERT 的其它语言实现已经非常丰富。更重要的是,YPTask 作为一个中间层次的系统,把大多数的配置和管理工作统一起来,极大地减少了业务代码需要处理的事,使得业务逻辑的开发和管理都变得很简单。我们会将这个工具进行进一步的调整和完善,并在合适的时候将其开源。

InfoQ::Erlang 与 Python、PHP 的通信是怎么做的呢,RPC 是使用 Thrift 还是其它的例子?

目前 Erlang 与工作进程(主要由 Python 开发)是通过 Erlang 的内置序列化方式 BERT 进行通信的,与 PHP 则是通过 JSON-RPC 通信的。考虑到我们系统的迁移,目前只实现了这两个对我们来说最合适的通信方式。不过我们打算加入更多的外部通信协议,比如 msgpack,protobuf 等等。

InfoQ:之前知乎使用又拍时曾出现一些故障,现在在安全性可靠性上,主要有哪些保障?

知乎在使用过程中出现的故障是由于他们对 API 的使用不当造成的。他们将需要认证的 API 请求放到客户端发送,导致向客户端泄漏了 API 的认证信息。从又拍的角度看,这也反映出之前的 API 功能还不够丰富,调用不够方便等问题。我们也会在这个方面投入更多的精力。

InfoQ:又拍的消息系统的规模有多大,下一步会怎么发展呢?

目前又拍的消息系统规模不算太大,每天由 5 个节点处理大约 500 万条消息。目前这些节点的压力并不大。下一步的发展还要看网站的发展情况来确定。

InfoQ:除了消息系统外,整个又拍架构中还有哪些优秀的地方想和读者分享?(又拍曾分享过分库设计)

又拍也是较早在架构中引入 Redis 的站点,可能的话可以分享一下相关经验。

2011-12-31 09:457309
用户头像

发布了 133 篇内容, 共 35.7 次阅读, 收获喜欢 1 次。

关注

评论

发布
暂无评论
发现更多内容

聚道云助力秒速对接,支付体验飞跃升级!

聚道云软件连接器

案例分享

解析SD-WAN带宽相关问题

Ogcloud

SD-WAN 企业组网 SD-WAN组网 SD-WAN服务商 SDWAN

Flink⼤状态作业调优实践指南:状态报错与启停慢篇

Apache Flink

大数据 flink

淘宝商品搜索API返回值详解:关键字搜索的数据应用策略

技术冰糖葫芦

API Explorer API 文档 pinduoduo API

制造业为什么需要质量管理系统

万界星空科技

质量管理 万界星空科技 QMS 生产质量

电力科学研究 涉及的IT系统

执于业务

今日区块链新闻及加密货币走向

dappweb

MySQL中insertOrUpdate的功能如何实现的

派大星

观测云与传统监控软件比,到底强在哪里?

可观测技术

监控 可观测性

云桌面成本效益分析:评估不同云桌面厂家的定价策略

青椒云云电脑

云桌面 云桌面厂家 云桌面方案

校园跑腿小程序系统,高效校友互动平台,校园校友系统,校园校友系统构建

DUOKE七七

php uniapp 社交交友 校园系统

云桌面厂商选择:避免常见错误指南

青椒云云电脑

云桌面 云桌面厂家 云桌面解决方案

國際知名榮譽顧問加入台灣分析集團總部,全面升級量子電腦Q系統

科技热闻

去中心化自治组织(DAO):重塑未来组织形态

dappweb

Mac电脑玩win游戏用什么?PD虚拟机和CrossOver玩游戏谁更好?

禁止废话

软件 Mac 软件 CrossOver Mac下载 虚拟机软件 pd 19

ClickHouse内幕(2)基础数据结构

京东科技开发者

douyin商品评论数据接口(douyin.item_review)丨douyin平台实时API接口指南

tbapi

抖音 抖音评论接口 抖音商品评论接口

助推企业数字化转型,MAXHUB连续三年荣膺“CIO信赖品牌”

科技热闻

代码高手的过节秘籍:CodeArt Snap帮写代码,灵感弹指间实现

华为云开发者联盟

人工智能 华为云 华为云开发者联盟 华为云CodeArts 企业号2024年6月PK榜

借助大模型技术,G7易流“智能接单”业务更高效、更精准

新消费日报

揭秘大模型价格战:差异化定价背后的“买的没有卖的精”

华为云PaaS服务小智

开发者 软件开发 华为云

从缺陷到创新:质量保障的新视角

京东科技开发者

如何找到适合您需求的云桌面厂家

青椒云云电脑

云桌面 云桌面厂家

WSPA台灣分部在2024年第二季度以6億美元TvPv表現亮眼

科技热闻

美团面试:说说Netty的零拷贝技术?

王磊

ClickHouse内幕(1)数据存储与过滤机制

京东科技开发者

社交软件红包技术解密(十三):微信团队首次揭秘微信红包算法,为何你抢到的是0.01元

JackJiang

网络编程 即时通讯 IM

圈子交友系统技术交流,创业分享,项目开发,前后端搭建,小程序/app/H5多端圈子社区论坛系统

DUOKE七七

php 开源 源码 uniapp 社交交友

淘宝/天猫获得店铺所有商品,taobao.item_search_shop API返回值技巧分享

技术冰糖葫芦

API Explorer api 货币化 API 文档 pinduoduo API

QFI 2024年第二季度創羽計畫再次啟動,臺灣分部學員迎來最後的絕佳機會並獲得專案補助資格

科技热闻

赵钟秋谈又拍网架构中的消息/任务系统_Erlang_黄璜_InfoQ精选文章