| 知乎专栏 |
消息队列并不是实时的，它不能替代传统 TCP/UDP Socket 通信。
消息生产者 —> 消息队列服务器 —> 消息消费者
消息队列中有 Switch (交换机) 的概念，事实上消息队列的工作方式的确跟网络交换机类似，网络交换机是TCP/UDP包的接收存储和转发，消息队列是消息的存储与转发。
从生产者到达消费者是有延迟的，尤其是多个生产者持续生产和多个消费者持续消费，消息服务器会出现瓶颈，消息会出现堆积情况，这时消息的生产和消费都会出现延迟，且时间不可控。
类似消息通知这种需求，是非实时的需求，不考虑发送延迟和达到时间，可以使用消息队列解决方案，否则还是使用 TCP Socket。
两个团队分别负责商品信息和价格还有库存功能模块的开发，商品信息是静态化方案，商品价格和库存是AJAX动态载入，公司重金从杭州淘宝挖了一名架构师，并给了首席架构师的头衔。
最终架构师给出的方案，更新商品信息时，后通过 ActiveMQ 通知刷新缓存更新价格和库存，这样的方案是否可行？我认为是可有可无，这个方案中消息队列并不是刚需。
出现了 这个需求是因为，商品促销需要经常调整价格和库存量。修改商品信息这个后台运营的操作，这种操作分成两类，一类是临时单品调价，另一类是批量调价。
我想问是否有必要更新商品价格？换个思路可以吗？是否还有其他更好的方案？
这里还有一个故事，于是促销需要，商品需要统一调价，程序猿给了一条SQL：
update goods set price=price+10 where category_id = xxx
高薪聘用的 DBA 竟然执行了，然后就悲剧了。
让我们换个思路去解决这个问题，我们专门来建一个促销打折表 discount 用来存储需要做促销的商品：
+----------------------------------------+ | discount | +----------------------------------------+ | Id | goods_id | price | ctime | mtime | +----------------------------------------+ | 1 | 100 | + 12.5 | xxx | xxx | | 2 | 101 | - 0.5 | xxx | xxx | +----------------------------------------+
当前价格 = 商品价格 + 折扣价格
相比 goods 表 discount 的数据量是非常小的，这样一来就无需异步执行，商品调价在Service 直接更新discount 表即可，刷新缓存也不过是一行代码，删除 cache key 在一个实例中完成原子性更好。