火币这种撮合是比较好水平扩展的

他不涉及到支付细节，不需要考虑银行网关、三方清算网关的压力，撮合交易的时候，只需要保证卖家的余额足够就可以）

哈哈哈哈，我还见过小时报的呢 （只不过是每天下班的时候一起发）

我去外地旅游了一趟，回来后第二天早上上班，发现车子居然没锁，而且锁也不见了。。。。。找了半天也不知道锁在哪里，我估计是小偷看我的小毛驴太破了。

哈哈，发错货了，这个理由很腻害哟

信用记录，但。。。人性是贪婪的，真正用上了还怎么收费删污点呢。。。所以可利用价值不高。

你们真好，每次我们编译一个 iOS 版本要半个小时，经常搞得测试闹情绪

越来越不喜欢京东，经常用天猫了

虽然京东把优惠券玩得很溜，但很让人反感，有些时候用了券才达到正常价格水平，并不是优惠多少钱

xml，我觉得的两个优势：
1. 写复杂的 SQL 比较方便
2. 统一管理，有其他同事接手工作的时候，或者其他同事优化数据库查询的时候，位置好找，修改便捷，不容易出错

没有

想读个在职的~

房产税肯定会有一定的免征面积，反正我又没几套房子，刚好自住够用，不担心。

墙裂资瓷

^_^ 有故事的人

@jjww

谢谢指教，不过我有不同意见：

经过挖坑、填坑，我其实并不推荐 redis 来实现队列之类的，不确定性太多：
1. 如果我要查询历史消费记录，还是需要存储到其他稳定可靠的介质里面
2. 引入 redis 之后需要考虑维护其稳定性

如果真的是要扩展，我愿意上成熟的方案：例如阿里云的消息队列（当然如果有专门的基础组件研发团队，这又另说）

我们都是自备纸巾啊，用完了找行政拿，干净卫生


卫生间的纸我不太敢用

只要面向接口编程，以后把 MySQL 队列替换成 MQ 队列就很方便

那啥啥啥，小项目，完全可以就地取材，MySQL 也可以很好地实现消息队列的。。。反正我们小项目都用 MySQL 做消息队列了，多一个组件，多一份危险；大项目再上 MQ，保证 MQ 的高可用性需要花很多精力的。

假设数据表 tab_task 大致这样的：
seq_id, is_active, create_time, update_time

其中 is_active = 0 标示待消费的，is_active = 1 表示正在被处理，is_active = 2 标示已经处理好的。

--------------------------------------------------
正常消费线程，获取一个待处理任务（在一个事务中执行）：

UPDATE tab_task SET `is_active` = 1 AND `seq_id` = LAST_INSERT_ID(`seq_id`)
WHERE AND `is_active` = 0
ORDER BY `seq_id` ASC LIMIT 1;

SELECT * FROM tab_task
WHERE ROW_COUNT() > 0 AND `seq_id` = LAST_INSERT_ID();

----------------------------------------------------

定期检查超时的任务，然后发送报警，获取一个超时的任务（假设超时时间为 5 分钟）：

SELECT * FROM tab_task
WHERE is_active = 1 AND NOW() > DATE_ADD(`update_time`, INTERVAL 5 MINUTE)


--------------------------------------------------

需要注意的是，你自己的服务器、开放平台都能收到用户消息，而且能分别向用户推送消息

@edison111cry 对对对，就是微信开放平台哈

你自己的代码逻辑不用变啊，微信推送消息、推送事件的时候 既要推送给你，也要推送给绑定的开放平台中的应用