docs: Discuss replacing memcached with redis more clearly.

This is a common question we get in architecture discussions.
This commit is contained in:
Tim Abbott 2019-03-18 12:25:11 -07:00
parent 58ca1ba5a4
commit 4f628fd945
1 changed files with 20 additions and 3 deletions

View File

@ -210,9 +210,26 @@ persistence:
# Zulip-specific configuration: disable saving to disk. # Zulip-specific configuration: disable saving to disk.
save "" save ""
memcached was used first and then we added Redis specifically to People often wonder if we could replace memcached with redis (or
implement rate limiting. [We're discussing switching everything over to replace RabbitMQ with redis, with some loss of functionality).
Redis.](https://github.com/zulip/zulip/issues/16)
The answer is likely yes, but it wouldn't improve Zulip.
Operationally, our current setup is likely easier to develop and run
in production than a pure redis system would be. Meanwhile, the
perceived benefit for using redis is usually to reduce memory
consumption by running fewer services, and no such benefit would
materialize:
* Our cache uses significant memory, but that memory usage would be
essentially the same with redis as it is with memcached.
* All of these services have low minimum memory requirements, and in
fact our applications for redis and RabbitMQ do not use significant
memory even at scale.
* We would likely need to run multiple redis services (with different
configurations) in order to ensure the pure LRU use case (memcached)
doesn't push out data that we want to persist until expiry
(redis-based rate limiting) or until consumed (RabbitMQ-based
queuing of deferred work).
### RabbitMQ ### RabbitMQ