# 为什么 Discourse 开始运行自己的 Redis 而不是使用 Elasticache？ **URL:** \ **Category:** Self-hosting\ **Tags:** hosting\ **Created:** [2019年一月27日 19:15 UTC](https://meta.discourse.org/t/why-did-discourse-start-running-their-own-redis-instead-of-using-elasticache/107658 "2019-01-27T19:15:27Z")\ **Posts on this page:** 1\ **Showing post:** 2
**Author:** ![Falco](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/falco/32/179432_2.png) [@Falco](https://meta.discourse.org/u/Falco)\ **Post date:** [2019年一月27日 19:27 UTC](https://meta.discourse.org/t/why-did-discourse-start-running-their-own-redis-instead-of-using-elasticache/107658/2 "2019-01-27T19:27:41Z")
Our main pain points were two. ### 1. Instance types Elasticache didn’t allow you to run HA Redis **without** Cluster Mode on instance types below M4.large. Support for cluster mode in Ruby Redis libraries is still being ironed out. MessageBus also does atomic operations on keys using LUA scripts and since that will span multiple servers it’s not allowed in cluster mode. We do host some BIG instances, so we may revisit using distributed writes for databases (Rails 6 is coming with that for PostgreSQL) but we aren’t needing this yet. We do host sites which need instance types way larger than that. But also host a lot where a t3.small is more than enough. Moving to running our own Redis allows us to pick and play with any instance types available in the target region. ### 2. Read only mode Discourse can keep a connection open with read only nodes with both Discourse and Redis. That allows people to keep reading on the site when masters go down. Elasticache wasn’t very straightforward in providing endpoints for the replicas in the main cluster, that updated to current replicas in failover events. --- _[View the full topic](https://meta.discourse.org/t/why-did-discourse-start-running-their-own-redis-instead-of-using-elasticache/107658)._