也谈淘点点60s短信订单的架构设计

本文涉及的产品
云数据库 Tair(兼容Redis),内存型 2GB
Redis 开源版,标准版 2GB
推荐场景:
搭建游戏排行榜
简介: 看到了这个 http://www.oschina.net/question/926166_2137672 然后有人写了博客还分析设计了一下 http://my.oschina.net/u/926166/blog/522227 本人最近对架构设计较感兴趣,下面是我的设计,可以做到极大化性能和水平扩展,所有的性能issue都在网络IO。

1. 前言

看到了这个 http://www.oschina.net/question/926166_2137672
然后有人写了博客还分析设计了一下 http://my.oschina.net/u/926166/blog/522227

本人最近对架构设计较感兴趣,下面是我的设计,可以做到极大化性能和水平扩展,所有的性能issue都在网络IO。redis存储方面轻松支持同时上亿个订单。

2. 基于redis的详细设计

  1. 使用一个高可用的时间序列发生器服务器。timeserver。
  2. 订单server产生了订单之后立即往redis的订单号服务器写一条记录,key为timeserver的nanosecond,存储类型为sorted set。把订单的详细信息写入另一个redis的详单服务器集群(用订单号hash写入)。
  3. 订单服务器有一个定时器线程,60s运行一次,时间到了发送一条消息(包含time server的当前nanosecond)给短信发送server。
  4. 短信发送server收到nanosecond的消息后,去redis订单号服务器取出所有小于该nanosecond的订单号,开启多个协程用订单号去redis详单服务器集群拿到详单数据,发送短信。
  5. redis配置成高可用。订单业务server和短信server都是无状态的,可以横向水平扩展。

3. 性能估计数据量估计

nanosecond为19个字符,并且nanosecond作为订单号,假设为20字符,那么20byte*100,000,000,一亿个订单的话,redis的订单号服务器需要大约 1.8GB 的内存。而redis的详单服务器可以水平扩展,存储不是问题。

4. 架构点评

  1. 订单server和短信server都是无状态,可水平扩展。
  2. redis存储节点高可用,redis详单服务器集群可水平扩展。
  3. 协程处理拿订单数据和发送短信,简单高效。
  4. 尽量避免了各种可预见的性能问题,例如:什么定时器,每隔1s轮询一次等等,另外也有对redis进行多次请求订单号的,都对性能有一些影响。
  5. 有的人的设计甚至把队列设计到了订单server内,这严重影响了订单server的扩展性,如果一旦订单server挂了呢?呵呵。
  6. 有人想要采用MQ的方式来做,但是如何搞定延时就是个大问题,因为MQ的方式是,Producer发送了之后,Consumer会立即接收到,如果你在Producer这边缓存60s之后在发送,那万一在这段时间该Producer挂了呢?呵呵。这里补充下,有人提到RabbitMQ的延迟队列,的确也是一中更加简单的方案。先发送到队列1,队列1不处理,超过60s队列系统自动发送到队列2,队列2的消费者进行处理。也是简单。呵呵。

5. 总结

  1. 这是一个非常实用的需求。
  2. redis是一个好东西,因为redis的设计和接口足够简单,所以我们没有太多想象,所以我们的设计也足够简单。简单才可能健壮。

文章转载自 开源中国社区[https://www.oschina.net]

相关实践学习
基于Redis实现在线游戏积分排行榜
本场景将介绍如何基于Redis数据库实现在线游戏中的游戏玩家积分排行榜功能。
云数据库 Redis 版使用教程
云数据库Redis版是兼容Redis协议标准的、提供持久化的内存数据库服务,基于高可靠双机热备架构及可无缝扩展的集群架构,满足高读写性能场景及容量需弹性变配的业务需求。 产品详情:https://www.aliyun.com/product/kvstore     ------------------------------------------------------------------------- 阿里云数据库体验:数据库上云实战 开发者云会免费提供一台带自建MySQL的源数据库 ECS 实例和一台目标数据库 RDS实例。跟着指引,您可以一步步实现将ECS自建数据库迁移到目标数据库RDS。 点击下方链接,领取免费ECS&RDS资源,30分钟完成数据库上云实战!https://developer.aliyun.com/adc/scenario/51eefbd1894e42f6bb9acacadd3f9121?spm=a2c6h.13788135.J_3257954370.9.4ba85f24utseFl
相关文章
|
1月前
|
消息中间件 存储 缓存
十万订单每秒热点数据架构优化实践深度解析
【11月更文挑战第20天】随着互联网技术的飞速发展,电子商务平台在高峰时段需要处理海量订单,这对系统的性能、稳定性和扩展性提出了极高的要求。尤其是在“双十一”、“618”等大型促销活动中,每秒需要处理数万甚至数十万笔订单,这对系统的热点数据处理能力构成了严峻挑战。本文将深入探讨如何优化架构以应对每秒十万订单级别的热点数据处理,从历史背景、功能点、业务场景、底层原理以及使用Java模拟示例等多个维度进行剖析。
55 8
|
7月前
|
消息中间件 架构师 NoSQL
以架构师的视角,深入剖析如何设计订单超时自动取消的功能
我们在美团 APP 下单,假如没有立即支付,进入订单详情会显示倒计时,如果超过支付时间,订单就会被自动取消。 这篇文章,笔者想以架构师的视角,深入剖析如何设计订单超时自动取消的功能。
以架构师的视角,深入剖析如何设计订单超时自动取消的功能
|
消息中间件 弹性计算 关系型数据库
使用EDA架构部署在线外卖订单系统
本实验将使用消息系统构建超级外卖订单,通过订单流转及处理阐述如何在多环境,复杂场景下使用消息做订单解耦,业务分发等。
|
NoSQL 算法 Java
千万级订单生成的痛点与架构
千万级订单生成的痛点与架构
194 0
|
存储 SQL 运维
基于 MySQL + Tablestore 分层存储架构的大规模订单系统实践-架构篇
本文简要介绍了基于 MySQL 结合 Tablestore 的大规模订单系统方案。这种方案支持大数据存储、高性能数据检索、SQL搜索、实时与全量数据分析,且部署简单、运维成本低。
基于 MySQL + Tablestore 分层存储架构的大规模订单系统实践-架构篇
|
存储 SQL 运维
大规模订单系统解读-架构篇
从最早的互联网高速发展、到移动互联网的爆发式增长,再到今天的产业互联网、物联网的快速崛起,各种各样新应用、新系统产生了众多订单类型的需求,比如购物订单、交流流水,外卖订单、支付账单、设备信息等。数据范围不仅越来越广,而且数据量越来越大,原有的经典架构方案已经很难满足当前新的业务场景。在新的需求下,对存储规模、开发效率、查询功能、未来扩展性等众多方面提出了更高的要求,要设计一款可靠稳定且扩展性好
7988 1
大规模订单系统解读-架构篇
|
存储 SQL 运维
基于 MySQL + Tablestore 分层存储架构的大规模订单系统实践-架构篇
背景订单系统存在于各行各业,如电商订单、银行流水、运营商话费账单等,是一个非常广泛、通用的系统。对于这类系统,在过去十几年发展中已经形成了经典的做法。但是随着互联网的发展,以及各企业对数据的重视,需要存储和持久化的订单量越来越大,数据的重视程度与数据规模的膨胀带来了新的挑战。首先,订单量对于数据的存储、持久化、访问带来了挑战,这不仅增加了开发面对的困难,也为系统的运维带来了挑战。其次,随着大数据技
2709 0
基于 MySQL + Tablestore 分层存储架构的大规模订单系统实践-架构篇
|
canal 存储 SQL
基于 MySQL + Tablestore 分层存储架构的大规模订单系统实践-数据同步 DTS 篇
前言 前文架构篇,可以看到 MySQL + Tablestore 非常适合大规模订单系统这一类需求场景。那么,我们首先要做的是,利用 CDC(Change Data Capture) 技术将订单数据实时从 MySQL 同步到 Tablestore 中。对于订单系统的数据同步,我们需要关注同步的稳定性、实时性。目前,存在多款工具可以实现这一功能,他们有的是开源工具如 Canal,有的是阿里云端服务如
1128 0
基于 MySQL + Tablestore 分层存储架构的大规模订单系统实践-数据同步 DTS 篇
|
canal NoSQL 关系型数据库
基于 MySQL + Tablestore 分层存储架构的大规模订单系统实践-数据同步 Canal 篇
前言 在基于 MySQL + Tablestore 分层存储架构的大规模订单系统中,利用 CDC 技术将 MySQL 数据同步到 Tablestore 是不可缺少的一步。前文已经详细讲述了如何使用 DTS 向 Tablestore 同步数据。对于中小规模的数据库,或者个人开发者,还可以使用 Canal 从 MySQL 向 Tablestore 同步数据。Canal 部署简单,易于运维,且相比于 D
737 0
基于 MySQL + Tablestore 分层存储架构的大规模订单系统实践-数据同步 Canal 篇
|
存储 SQL 运维
基于 MySQL + Tablestore 分层存储架构的大规模订单系统实践-订单搜索篇
背景在大规模订单系统中,存在以下常见需求:查询某店铺过去一段时间成交额查询某品牌商品在过去一周内的成交额查询在某店铺购物的客户列表……因此,开发者对于数据库在非主键查询、多列的自由组合查询等复杂查询需求上会有比较高的要求。传统的订单系统会使用 Elasticsearch 或者 Solr 来实现这一需求,但伴随而来的是更高的系统复杂度和更加昂贵的系统维护成本。Tablestore 的多元索引,能够支
1046 0
基于 MySQL + Tablestore 分层存储架构的大规模订单系统实践-订单搜索篇