消息队列
?
一 应用场景
有很多业务, 客户端和内网都要进行数据传输和交换, 现有架构中, 客户端不能直接访问内网,?
那么客户端只能: 先把数据保存到外网服务器, 然后内网服务器再拉回来处理. 这种方式可以保证数据
都能被处理, 但实效性不够.
?
通常, 外网服务器只起到一个暂时保存数据的作用, 保存客户端报上来的数据, 然后等待内网来拉走,
把客户端看做producer, 内网看做consumer, 这正是消息队列的用武之地.
客户端先把数据写入外网服务器的消息队列, 然后内网服务器再从消息队列取走数据, 消息队列须满足:
(1) 支持高并发的入队和出队操作, 允许很多客户端同时插入数据, 而且允许内网服务器高频率地取走
? ? ? 数据
(2) 支持数据的持久化, 为保证速度, 消息队列缓存在内存中, 如果内存不够用了, 则写入磁盘.
(3) 支持一次性插入多条记录, 以及一次性取走多条数据, 这样可以提高传输效率
?
二 技术选型
1 存储方案: Tokyo Cabinet
Tokyo Cabinet数据库是日本最大的社交网站mixi开发的一款Key-Value数据库，之所以选择Tokyo Cabinet,
而不是MySQL, Redis或者Memcached, 这是因为:
?
(1) Tokyo Cabinet的读写速度非常快, 比MySQL快很多, 和Memcached差不多, 比Redis当然慢一截,
? ? ? 有测试数据为证:
写入100万条：tcbtest write test.tcb 1000000
时间: 0.994秒 速度：100,6036条/秒
写入200万条：tcbtest write test.tcb 2000000
时间: 2.028秒 速度： 98,6193条/秒
写入500万条：tcbtest write test.tcb 5000000
时间: 5.276秒 速度： 94,7687条/
?
(2) Tokyo Cabinet占用内存不大, 而且支持数据的持久化, 用户可以设定内存缓存的大小, 缓存不够用
? ? ?的时候,?就把数据持久化到磁盘
?
2 网络接口: Libevent
Tokyo Cabinet只是一个数据存储层面的东西, 它没有提供网络接口, 所以得写一个http服务器为用户
提供服务.对于高并发的服务器来说, 基于事件驱动的libevent网络库是非常好的选择. 事实上, libevent
自带了一个简单高效的http服务器实现, 对于消息队列服务器来说足够使用了. 代码不足400行.
?
?
三 如何使用
用户使用http的get请求来操作消息队列. 参数如下
o: 操作参数, 取值为{get|set|status}, set表示入队,get表示出队, status查看队列的状态
m: 消息数据.
p: 密码参数或者校验参数
n: 一次入队n条消息, 或者出队n条消息
?
1 入队
http://localhost:3333/dsr?o=set&d=foobar|hello|world
把foobar, hello, world三条消息插入队列,消息之间用"|"号隔开，若成功入队, 服务端返回0#0
?
?
2 出队
http://localhost:3333/dsr?o=get&n=10
从队列中取出10条消息, 每条消息以换行符隔开.
?
?
3 状态
http://localhost:3333/dsr?o=status
查看队列的状态,显示队列的容量, 当前消息数量, 队列头指针, 队列尾指针:
?
?
四 压力测试
测试环境 : 8核CPU
1 入队操作
1000并发量, 插入10万条消息, 每条消息512字节
* 使用keep-alive
测试结果:21246 qps, 占用磁盘空间: 51M
* 不使用keep-alive
测试结果:12768 qps, 占用磁盘空间: 51M
?
2 出队操作
1000并发量, 每次取走一条消息, 取10万次
* 使用keep-alive
测试结果: 27709 qps
* 不使用keep-alive
测试结果: 11461 qps
?
从测试结果来看, 消息队列的读写性能都非常不错, 应该能够满足很多应用的需求
?
