也谈淘点点60s短信订单的架构设计
2015-10-27 14:39
961 查看
1. 前言##
看到了这个 http://www.oschina.net/question/926166_2137672然后有人写了博客还分析设计了一下 http://my.oschina.net/u/926166/blog/522227
本人最近对架构设计较感兴趣,下面是我的设计,可以做到极大化性能和水平扩展,所有的性能issue都在网络IO。redis存储方面轻松支持同时上亿个订单。
2. 基于redis的详细设计##
使用一个高可用的时间序列发生器服务器。timeserver。订单server产生了订单之后立即往redis的订单号服务器写一条记录,key为timeserver的nanosecond,存储类型为sorted set。把订单的详细信息写入另一个redis的详单服务器集群(用订单号hash写入)。
订单服务器有一个定时器线程,60s运行一次,时间到了发送一条消息(包含time server的当前nanosecond)给短信发送server。
短信发送server收到nanosecond的消息后,去redis订单号服务器取出所有小于该nanosecond的订单号,开启多个协程用订单号去redis详单服务器集群拿到详单数据,发送短信。
redis配置成高可用。订单业务server和短信server都是无状态的,可以横向水平扩展。
3. 性能估计数据量估计##
nanosecond为19个字符,并且nanosecond作为订单号,假设为20字符,那么20byte*100,000,000,一亿个订单的话,redis的订单号服务器需要大约 1.8GB 的内存。而redis的详单服务器可以水平扩展,存储不是问题。4. 架构点评
订单server和短信server都是无状态,可水平扩展。redis存储节点高可用,redis详单服务器集群可水平扩展。
协程处理拿订单数据和发送短信,简单高效。
尽量避免了各种可预见的性能问题,例如:什么定时器,每隔1s轮询一次等等,另外也有对redis进行多次请求订单号的,都对性能有一些影响。
有的人的设计甚至把队列设计到了订单server内,这严重影响了订单server的扩展性,如果一旦订单server挂了呢?呵呵。
有人想要采用MQ的方式来做,但是如何搞定延时就是个大问题,因为MQ的方式是,Producer发送了之后,Consumer会立即接收到,如果你在Producer这边缓存60s之后在发送,那万一在这段时间该Producer挂了呢?呵呵。
这里补充下,有人提到RabbitMQ的延迟队列,的确也是一中更加简单的方案。先发送到队列1,队列1不处理,超过60s队列系统自动发送到队列2,队列2的消费者进行处理。也是简单。呵呵。
##5. 总结##
这是一个非常实用的需求。
redis是一个好东西,因为redis的设计和接口足够简单,所以我们没有太多想象,所以我们的设计也足够简单。简单才可能健壮。
相关文章推荐
- redis安装问题小结
- 架构纵横谈之二 ---- 架构的模式与要点
- 一步一步跟我学易语言之第二个易程序菜单设计
- Redis偶发连接失败案例实战记录
- BS项目中的CSS架构_仅加载自己需要的CSS
- Redis中实现查找某个值的范围
- Redis和Memcached的区别详解
- 分割超大Redis数据库例子
- Redis总结笔记(一):安装和常用命令
- Redis sort 排序命令详解
- 用Redis实现微博关注关系
- redis中修改配置文件中的端口号 密码方法
- 在Ruby on Rails上使用Redis Store的方法
- 关于三种主流WEB架构的思考
- Redis和Memcache的区别总结
- 基于逻辑运算的简单权限系统(原理,设计,实现) VBS 版
- C#中设计、使用Fluent API
- 在Node.js应用中使用Redis的方法简介
- Android操作系统的架构设计分析
- Redis服务器的启动过程分析