Có thể bạn không cần Redis

• Redis là một trong những công nghệ có danh tiếng tích cực nhất trong ngành công nghệ
  • Đây là một công nghệ xuất sắc, được thiết kế rất tốt và bản thân nó không có khuyết điểm, nhưng có thể không phải lúc nào cũng cần thiết
• Trong hơn 10 năm, tác giả đã thấy cùng một mô thức ở 3 công ty:
  • Vấn đề xuất hiện và Redis trông có vẻ phù hợp, nhưng trên thực tế либо không cải thiện được tình hình, либо không giải quyết được vấn đề gốc rễ
  • Nó chỉ đơn thuần là thêm phức tạp vì sự phức tạp

Trường hợp thứ nhất: trải nghiệm tại Tantan

• Tantan là ứng dụng hẹn hò lớn thứ hai tại Trung Quốc và vận hành 50~100 máy chủ cơ sở dữ liệu hiệu năng cao dựa trên PostgreSQL
• Mỗi máy chủ được sharding theo ID người dùng, nên dữ liệu của một người dùng cụ thể chỉ được lưu trên một máy chủ
• Tình huống vấn đề
  • Xuất hiện yêu cầu phải lưu số lượt 'vuốt' và cập nhật nhanh
  • Ban đầu đánh giá rằng lưu vào Redis là phù hợp
  • Nghĩ rằng chỉ cần vài máy chủ Redis hiệu năng cao là đủ nên đã tiến hành cấu hình
• Xem xét lại và giải pháp
  • Trong nhóm đã thảo luận phương án lưu trực tiếp vào PostgreSQL thay vì Redis
  • Vì tải trên các máy chủ PostgreSQL vốn đã cao nên dự đoán tải bổ sung sẽ không đáng kể
  • Sau khi lưu vào PostgreSQL cũng không có suy giảm hiệu năng, và việc đưa Redis vào là không cần thiết

Trường hợp thứ hai: trải nghiệm tại Bannerflow

• Bối cảnh
  • Bannerflow là nền tảng tạo và phát hành quảng cáo
  • Trong một microservice mới, nhóm quyết định đưa Redis vào để hỗ trợ phát hành quảng cáo lên các mạng xã hội như Facebook
• Tình huống vấn đề
  • Trong bối cảnh tải thấp hơn Tantan rất nhiều, không rõ việc đưa Redis vào có thực sự cần thiết hay không
  • Sau khi nhà phát triển ban đầu rời đi, không còn ai có thể giải thích rõ lý do đưa Redis vào
• Kết quả
  • Redis không thực sự cần thiết vì tải thấp
  • Về lâu dài, nhóm đi đến kết luận rằng loại bỏ Redis là phương án tốt nhất

Trường hợp thứ ba: trải nghiệm tại MAJORITY

• Bối cảnh
  • MAJORITY là một công ty fintech đã đưa Redis vào để cache kết quả gọi API bên ngoài
  • Redis được dùng để cache dữ liệu tra cứu vị trí nhằm tăng tốc độ xử lý và giảm chi phí
• Tình huống vấn đề
  • Cùng một dữ liệu cũng được lưu trong DB (Azure SQL)
  • Dự đoán rằng ngay cả khi thay lời gọi Redis bằng lời gọi DB thì tải tăng thêm cũng gần như không đáng kể
  • Nhóm định tiếp tục dùng Redis vì cần xử lý lock, nhưng Azure SQL đã có thể xử lý đầy đủ
• Kết quả
  • Đi đến kết luận rằng việc đưa Redis vào là không cần thiết
  • Lập kế hoạch chuyển sang dùng Azure SQL thay cho Redis

Kết luận

• Cả ba trường hợp đều xảy ra ở những domain, tech stack và điều kiện tải khác nhau
• Điểm chung là việc đưa Redis vào một cách không cần thiết
• Trước khi đưa Redis vào, cần cân nhắc kỹ nhu cầu thực tế và lợi ích về hiệu năng
• Khuyến nghị bài nói chuyện 'Choose Boring Technology' của Dan McKinley

[iolothebard]

Bất kể có dùng Redis hay không, việc đặt một lớp cache giữa domain và persistence — với triển khai mặc định là bypass — hoàn toàn không phải là over-engineering. Nó phục vụ cho logging, dữ liệu giả, gỡ lỗi, profiling, và có thể cả cache thực sự…

[nodelay]

+1 Tôi cũng đồng ý. Chỉ cần thêm một lớp thôi là cũng đã tạo ra khoảng trống, và mở ra không gian để giải quyết vô số việc.

[galadbran]

Có vẻ góc nhìn ở đây không phải là Redis có vấn đề, mà là nếu chỉ DB thôi đã đủ thì tại sao lại phải đưa thêm một thành phần nữa vào để làm tăng gánh nặng vận hành.
Bài viết giải thích khá ngắn gọn, nên có lẽ chỉ cần tiếp nhận theo hướng rằng đây cũng là một góc nhìn đáng để cân nhắc.
Cũng có những tình huống mà việc đưa Redis cache vào trong khi vẫn giữ logic ứng dụng đơn giản sẽ là lựa chọn tốt hơn,
vì vậy có lẽ vẫn nên chọn tùy theo hoàn cảnh.

[zinisuni]

Đúng là tiêu đề khá câu view. Haha, tôi đồng ý~~

[GN⁺]

Ý kiến trên Hacker News

• Khi làm việc tại Uber vào năm 2015, đã có nỗ lực chuyển từ cách phân chia địa lý theo mã bưu chính sang phương pháp dựa trên lục giác

  • Thay vì chia một thành phố thành vài chục mã bưu chính, hệ thống chia thành hàng trăm nghìn ô lục giác và tạo vùng một cách động
  • Bản phát hành đầu tiên diễn ra ở Phoenix, và cả nhóm đã thức trắng đêm để mở rộng hệ thống định giá theo nhu cầu
  • Việc triển khai toàn cầu đã bị trì hoãn
  • Có nhiều kỹ sư rất thích Redis
  • Dịch vụ định giá dựa trên Redis và xử lý hàng triệu yêu cầu
  • Chi phí cao và cũng gặp vấn đề về khả năng mở rộng
  • Sau khi cải tiến thuật toán, có thể tính toán các vùng động cho nhiều thành phố trên một máy duy nhất
  • Một kỹ sư tên Isaac đã triển khai và đưa vào vận hành trong một cuối tuần

• Đã có tranh luận về việc lạm dụng Redis

  • Redis rất hay, nhưng khi dùng sẽ phát sinh độ trễ mạng và overhead tuần tự hóa
  • Nếu dữ liệu đã được phân mảnh sẵn, một hash map thông thường có thể tốt hơn
  • Trong Java có ConcurrentHashMap, Guava Caches, Caffeine Caches, v.v.
  • Tự triển khai cache cục bộ gần như luôn nhanh hơn dùng mạng
  • Redis có xu hướng bị dùng quá mức

• Văn hóa sử dụng Redis chưa phát triển tương xứng với mức độ phổ biến của nó

  • Redis hỗ trợ nhiều cấu trúc dữ liệu, và khi văn hóa kỹ thuật trong công ty trưởng thành hơn thì có thể học thêm nhiều pattern hơn
  • Điều đáng tiếc là không có một tuyển tập pattern cho Redis

• Vấn đề không phải là Redis hay không Redis, mà là làm việc với dữ liệu khó tuần tự hóa

  • Với bộ đếm, news feed, tin nhắn chat, v.v., Redis có thể hiệu quả hơn
  • Trong phần lớn trường hợp, MySQL cũng đã đủ dùng

• Phát triển phần mềm thường có xu hướng lặp lại cách làm của người khác

  • Bắt đầu từ Memcached rồi phát triển sang Redis
  • Có xu hướng dùng cache để tránh độ phức tạp của cơ sở dữ liệu
  • Cơ sở dữ liệu vẫn phức tạp và khó khăn

• Redis là "máy chủ cấu trúc dữ liệu" sẵn sàng cho production duy nhất

  • Hữu ích khi nhiều instance cùng truy cập một dịch vụ giống nhau

• Có thể bạn không cần cache

  • Có kinh nghiệm tập trung cải thiện kiến trúc mà không đưa cache vào

• API của Redis rất xuất sắc, nhưng có rủi ro trong vận hành

  • Dùng làm cache thì tốt, nhưng không đáng tin cậy khi làm kho lưu trữ dữ liệu production

• Việc có xu hướng không khuyến nghị dùng Redis là điều gây ngạc nhiên

  • Redis vẫn cung cấp cấu trúc dữ liệu tuyệt vời và hiệu năng cao

• Redis ổn khi làm cache tạm thời, nhưng còn thiếu cho giao dịch hoặc lưu trữ phân tán

  • Cần học về vấn đề distributed locking