Gọn nhẹ nhưng vừa đủ!

Nói chán #Database rồi thì giờ cũng đến lúc nói đến #cache rồi mọi người nhỉ, rốt cuộc có vẽ vời kiến trúc lọ chai thế nào thì một hệ thống cơ bản cũng chỉ xoay quanh mấy thành phần: #service, #memory #caching và #database mà thôi

Đã nói về cache thì chắc chắn là phải nói đến #Redis đầu tiên rồi, ngày xưa #Redis và #memcached tạo thành 1 cuộc đua song mã thì giờ đây khi #memcached đã bỏ cuộc thì lại có cuộc đua giữa #Redis và #Hazelcast. Nhưng có vẻ #Redis vẫn được ưa chuộng hơn, vì đi đâu, làm dự án nào mình cũng thấy có #Redis.

Đơn giản để chiếm ưu thế

Về cơ bản thì Redis chiếm lợi thế là đúng, bởi vì Redis chỉ đơn giản là một nơi lưu giữ một cái #Map giữa key và value, và tất cả ở dạng byte[] hết còn việc serialize và deserialize (gọi tắt là Protocol) thế nào thì mặc cho developer muốn dùng kiểu gì thì dùng. Người thì dùng #Protobuf, người thì dùng #MsgPack, người thì dùng #Json. Cá nhân mình đã tham gia các dự án dùng Redis thì mỗi dự án code 1 kiểu, mỗi dev lại có các lý lẽ khác nhau cho việc lựa chọn #Protocol. Nhưng theo mình thì ĐỪNG nên dùng Json, hãy dùng #Protobuf hoặc #MsgPack. Tại sao vậy?

Đừng dùng JSON

Khi làm gì thì cũng hãy nhớ lý do bắt đầu, và lý do chúng ta dùng cache là để tối ưu tốc độ, mà cái gì làm ảnh hưởng tới tốc độ, đó chính là dung lượng gói tin truyền qua giữa các node (server) thế mà bây giờ dùng json, dung lượng gói tin sẽ bị lớn (vì json là string, mà mỗi kí tự tối thiểu là 1 byte rồi) thì rốt cuộc chúng ta có tối ưu được gì không? Thế nên hãy dùng các protocol như #Protobuf hay #Msgpack để giảm thiểu dung lượng gói tin ở mức tối thiểu khi truyền qua các #node

Khi nào dùng Redis?

Ngày xưa mình cũng say mê cache lắm, vì thích công nghệ mà, làm cái gì cũng phải cố nhét cache vào để nâng tầm hiểu biết với cả thể hiện bản thân, nhưng đã gần 1 năm nay mình không còn dùng cache nữa, vì hoá ra không có cache mọi thứ vẫn cứ nhanh, 🙂, vậy nên theo mình #Redis phù hợp với những dự án:

  1. Cần chia sẻ thông tin giữa các node, và thông tin này cần truy xuất rất nhanh, ví dụ như lưu session token chẳng hạn, một cái map giữa sessionToken và userId sẽ giúp cho chúng ta chia sẻ được token giữa các node và lại tăng được hiệu năng hơn là dùng database
  2. Các dự án cần performance cực nhanh như là #game hay các dự án tài chính #fintech hay #chat. Đối với game thì cũng nên cân nhắc các tính năng cần thiết như đồng bộ vị trí của user. Đối với #fintech thì cũng cân nhắc các chức năng như là thanh toán, đặt lệnh, hay lưu giữ các chỉ số
  3. Còn gì nữa không nhỉ, nghĩ ra mình sẽ edit sau, 🙂

Tổng kết

Theo quan điểm của mình thì việc dùng cache là không bắt buộc, hãy chỉ dùng khi cảm thấy thật cần thiết để tránh đội chi phí vận hành cho doanh nghiệp nhé. Bài viết này còn rất sơ khai, hãy đón chờ loạt bài về Redis nhé mọi người, 🙂

Tham khảo

  1. Redis vs memcached
  2. Redis vs hazelcast
  3. Với spring-redis
  4. Với ezydata-redi