关于淘点点面试中碰到的架构问题

       从事开发工做两年来，从未写过只言片语，俗话说的好”好记性不如烂笔头“，最近心血来潮开始想慢慢写点博文，不只是知识的积累仍是为了若干年后回头看看当年努力的过程，但愿把这个养成习惯并坚持下去，啰嗦了这么久 来点干货把。

      以前面试淘点点的时候被问倒得一个问题至今牵挂，因为工做环境的限制，我没能接触到一些大数据量的并发工做，也没能有机遇参与复杂系统的设计，而我学习复杂或高并发系统的惟一途径就是阅读源码，惭愧的是，至今也只阅读了Tomcat的部分源码，因而我在oschina上贴出问题与互联网猿一同分析（你们能够先看看问题：关于淘点点面试中碰到的架构问题），很是感谢你们的意见，尤为是@林中漫步 @JerryLin 两位先生 最终肯定两钟实现思路：

一、具备排序功能的队列

二、Redis+定时器

思路 1

原理：第一种思路也就是你们推荐的延迟队列实现的原理，其就是一个按时间排好序的队列，每次put的时候排序，而后take的时候就计算时间是否过时，若是过时则返回队列第一个元素，不然当前线程阻塞X秒，这个也是JDK 自带 DelayQueue 的思路。详细可看源码

代码实现：待实现后补充

思路 2

原理：第二种思路须要利用Redis的有序集合，说到使用 Redis 就不得不考虑Score的设计，由于它直接决定你代码的复杂度，你思路的清晰性，在这我并无采用 林中漫步 先生的设计，而是经过精确到秒的时间作Score（去掉毫秒），而后使用线程每一秒扫一次，使用当前时间做为zrangeBysocre命令的Score去查询。详细请看代码。

业务场景：按京东一天500万的成交量，一天主要成交时间为8小时，计算得出每秒173个订单，固然实际上订单不能均匀分布在每秒，但咱们主要为了论证思想的可行性。

代码实现：这里首先我简单的利用Spring Scheduled做为订单的生产者，每一秒制造170个订单，放入Redis，注意Score的生成，为当前时间的后60秒，removeMillis()生成去掉毫秒的时间戳做为Rredis的Zadd方法的 Score（不了解的能够百度下）。

第二步：一样利用Spring Scheduled 一秒钟心跳一次，每次利用当前时间做为Key 从Redis 取数据。

通过测试，没有出现漏单的状况，这只是简单的实现，不少地方能够优化，在实际中用也可能会出现不少问题，须要不断完善，此案例只是提供思路，另外我以为JDK的 DelayQueue 相对于Redis来讲没有那么好，由于Queue毕竟每次取一个，若是同一时间的比较多可能不能符合当前这种时间严谨的需求，另外他是单机的，有时间我去研究下kafka、Rabbit的延迟队列再来补充。

终于写完了，由于公司的代码是加密的，因此不能上传源码了（其实也没得什么上的，哈哈），另外本人技术有限不免会有纰漏或者错误，欢迎拍砖，另外但愿本身之后可以坚持写技术日志。

版权全部，转载请注明出处 http://my.oschina.net/u/926166/blog/522227