4

So I am currently working on a chat, and I wonder if I could use Redis to store the chat messages. The messages will be only at the web and I want at least a chat history of 20 messages for each private chat. The Chats subscribers will be already stored in MongoDB.

I mainly want to use Redis, because I get rid of the MongoDB stuff, for more speed.

I already use Pub/Sub, but what about storing a copy in Redis Lists? Also what about reading statuses, how could I implement that?

Daniel O
  • 365
  • 1
  • 2
  • 7
  • Well, that depends if you might need to access these messages later, because you can't truly trust redis, because it's not meant for longterm data storing. If for example your redis server restarts, the data will be gone. If you don't really care about that, then yeah go for it – SpeekaDievs Aug 29 '17 at 07:10

2 Answers2

2

Redis only loses data in case of power outage, if the system is shutdown properly, it will save its data and in this case, data won't be lost.

It is good approach to dump data from redis to mongoDb/anyotherDb when a size limit is reached or on date basis (weekly or monthly) so that your realtime chat database stays light weighted.

Many modern systems now a days prepare for power outage, a ups will run and the system will shutdown properly. see : https://hackernoon.com/how-to-shutdown-your-servers-in-case-of-power-failure-ups-nut-co-34d22a08e92

Also what about reading statuses, how could I implement that?

Depends on protocol you are implementing, if you are using xmpp, see this. Otherwise, you can use a property in message model for e.g "DeliveryStatus" and set it to your enums (1. Sent, 2. Delivered, 3. Read). Mark message as Sent as soon as it is received at server. For Delivered and Read, your clients will send you back packets indicating the respective action has occurred.

Mohsin
  • 692
  • 1
  • 7
  • 15
0

As pointed in the comment above, the important thing to consider here is the persistency model. Redis offers some persistency (with snapshots and aof-files). The important thing is to first understand what you need:

can you afford to lose all the data? can you afford to lose some of the data? if the answer is no, then perhaps you should not bother with redis.

FuzzyAmi
  • 7,543
  • 6
  • 45
  • 79