簡述基於redis和數據庫實現的消息系統

首先要肯定一個無能否認的事實，redis裏的數據是易失的，因此用redis只是爲了作到高性能的發佈通知。 其次以下所說的只是簡化版，極爲簡陋，但骨架子確實是能搭出來的

• 在數據庫中創建一個消息表，有uuid,message,timestamp,is_used幾個字段
• 每次往消息表推送一條消息後，把消息的uuid經過RPUSH指令推送到redis
• 取消息的進程使用BLPOP經過阻塞模式接收消息，收到uuid後從數據庫的消息表裏取出message進行後續操做，取的同時設置is_used = 1，或者能夠根據業務，select for update那條消息，業務確實處理完成後再設置爲1，這都是數據庫自己的事，和redis的不可靠性無關
• redis可能因各類緣由，丟失uuid，則須要一個獨立的服務檢測長時間未處理(timestamp > timeout and is_used = 0)的uuid，再次推送到redis中

接下來是一些QA

Q：如何解決重複推送uuid到redis中

A：redis只是爲了協調分佈式系統中多個組件，使其儘快處理消息，實際併發控制和防重複的控制在數據庫

Q：必定要用uuid嗎？

A：啥id都行，找到message就好了

Q：和postgres的queue有啥區別

A：用postgres自身的notify/listen和數據表實現的隊列，一個監聽服務就要開啓一個數據庫鏈接進程，若是監聽的服務比較多，對數據庫資源有點浪費。優點就是postgres的notify雖然也有瑕疵，但不會斷電丟失。