Kami menggunakan Redis di Trello untuk data singkat yang tidak masalah jika kami kehilangan. Kami tidak menyimpan data di Redis ke disk, dan kami menggunakannya allkeys-lru, jadi kami hanya menyimpan hal-hal di sana yang dapat dikeluarkan kapan saja dengan hanya ketidaknyamanan yang sangat kecil bagi pengguna (misalnya, untuk sementara melihat status pengguna yang salah). Meskipun demikian, kami memberikannya lebih dari 5x ruang yang dibutuhkan untuk menyimpan perangkat kerja aktualnya dan memilih dari 10 kunci untuk masa berlakunya, jadi kami benar-benar tidak pernah melihat ada yang dikeluarkan yang kami gunakan.
-
Ini adalah server pubsub kami. Ketika pengguna melakukan sesuatu ke papan atau kartu, kami ingin mengirim pesan dengan delta itu ke semua klien yang terhubung ke websocket yang berlangganan objek yang diubah, jadi semua proses Node kami berlangganan ke saluran pubsub yang menyebar pesan-pesan itu, dan mereka menyebarkannya ke soket web yang diizinkan dan berlangganan dengan tepat.
-
Kami agak menggunakannya untuk mendukung socket.io, tetapi karena kami hanya menggunakan soket web, dan karena socket.io terlalu cerewet untuk skala seperti yang kami butuhkan saat ini, kami memiliki tambalan yang menonaktifkan semua kecuali satu saluran yang penting bagi kami.
-
Untuk pengguna kami yang tidak memiliki soket web, kami harus menyimpan daftar tindakan yang telah terjadi pada setiap saluran objek sejak permintaan polling terakhir pengguna. Untuk itu kami menggunakan daftar yang kami batasi pada 100 elemen terbaru, dan penghitung tambahan dari berapa banyak elemen yang telah ditambahkan ke daftar sejak dibuat. Jadi ketika kita menjawab permintaan polling dari browser seperti itu, kita dapat memeriksa elemen terakhir yang dilaporkan telah dilihatnya, dan hanya mengirim pesan yang telah ditambahkan ke antrian sejak saat itu. Sehingga permintaan jajak pendapat turun menjadi hanya pemeriksaan izin dan pemeriksaan kunci Redis tunggal dalam banyak kasus, yang sangat cepat.
-
Kami menyimpan beberapa data singkat tentang status aktif pengguna yang terhubung di Redis, karena data itu sering berubah dan tidak perlu menyimpannya ke disk.
-
Kami menyimpan kunci yang berumur pendek untuk mendukung login OAuth di Redis.
Kami mencintai Redis; setelah Anda memiliki instance dan berjalan, Anda ingin menggunakannya untuk semua jenis hal. Satu-satunya masalah nyata yang kami hadapi adalah klien yang memakan waktu lama menghabiskan ruang yang tersedia.
Kami menggunakan MongoDB untuk kebutuhan database kami yang lebih tradisional.
