订单

记录开发过程中遇见的问题。订单数据属于历史数据，作为以后的参考查询使用，不应当直接作为业务数据使用，要是历史数据要使用在业务逻辑中，进行相应的增删改查，那历史数据就应当流进业务数据之中。 举个开发中的例子来讲: 有课程 ， 课件 ， 用户 三个实体 ，其中一个课程包含多个课件。 那么在用户购买课程的产生的订单数据中 ， 就应该包含两部分数据。 订单（用户 ， 课程） ， 订单课件（订单，课件）。 1----》订单中，必须包含课件的会变动属性，例如课程的价格 ， 课程的名称 等等， 作为历史数据存在 ， 订单数据一定是不随着课程的变化而变化的。这一点在一些刚入手项目的程序员中经常会犯错误， 认为只是关联上课程ID就万事大吉。 2----》订单课件 是为了记录当时的课程包含课件情况。在生活中很明显， 你买了电脑500G硬盘， 不会因为厂家过后把该型号硬盘改成750G ， 你的机器也变为750G。 但是在开发中确实会出问题， 尤其是对于刚入手项目的开发人员 ， 对业务不很熟悉。 以上内容仅供参考， 在此写出， 确有其事。 希望有用。 来源： oschina 链接： https://my.oschina.net/u/195896/blog/71469

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. 性能估计数据量估计##