31
4
Trước hết hãy nghĩ xem Redis có phù hợp với hàng đợi tin nhắn hay không?
Không có gì hơn ngoài những điểm sau:
0. Dữ liệu có thể được đọc tuần tự 1. Hỗ trợ chặn và chờ kéo tin nhắn 2. Hỗ trợ chế độ xuất bản/đăng ký 3. Tiêu thụ lại 4. Tin nhắn không bị mất 5. Tin nhắn có thể được tích lũy.
Sau đó hãy xem redis đáp ứng những nhu cầu này như thế nào.
Bản thân danh sách truy cập dữ liệu theo thứ tự vào trước, ra trước. Việc triển khai cơ bản là "danh sách liên kết". Độ phức tạp về thời gian của các phần tử vận hành ở đầu và cuối là O(1), có nghĩa là nó rất phù hợp với mô hình hàng đợi.
Nhà sản xuất sử dụng LPUSH để xuất bản thông điệp:
Trung tâm cá nhân
Điều phát hành
từ bỏ
127.0.0.1:6379> LPUSH mq 5 (số nguyên) 1 127.0.0.1:6379> LPUSH mq 3 (số nguyên) 2
Người tiêu dùng sử dụng RPOP để lấy tin nhắn
127.0.0.1:6379> RPOP mq 5 127.0.0.1:6379> RPOP mq 3
Khi không có tin nhắn nào trong hàng đợi, người tiêu dùng sẽ trả về NULL khi thực thi RPOP.
127.0.0.1:6379> RPOP mq (không)
Khi người tiêu dùng đọc dữ liệu, sẽ có một điểm rủi ro về hiệu suất tiềm ẩn:
Khi nhà sản xuất ghi dữ liệu, List không chủ động thông báo cho người tiêu dùng rằng có tin nhắn mới được viết. Nếu người tiêu dùng muốn xử lý tin nhắn kịp thời, họ cần liên tục gọi lệnh RPOP trong chương trình. Nếu một thông báo mới được viết, lệnh RPOP sẽ trả về kết quả. Ngược lại, lệnh RPOP sẽ trả về giá trị null và tiếp tục vòng lặp.
// Mã giả while (true) { var msg = redis.rpop("mq") if(msg == null) continue xử lý(msg) }
Nếu hàng đợi trong đoạn mã trên trống, người dùng vẫn sẽ thường xuyên lấy tin nhắn, điều này sẽ gây ra hiện tượng "CPU không hoạt động", không chỉ lãng phí tài nguyên CPU mà còn gây áp lực lên Redis.
Hãy giải quyết nó. Khi hàng đợi trống, chúng ta có thể "ngủ" một lúc và thử kéo lại tin nhắn.
// Kiểm tra while (true) { var msg = redis.rpop("mq") if(msg == null) { Thread.Sleep(2000); continue; } handle(msg) }
"CPU chạy không tải" đã được giải quyết, nhưng một vấn đề mới lại xảy ra: khi có một tin nhắn mới trong khi người tiêu dùng đang ngủ và chờ đợi, quá trình xử lý tin nhắn mới của người tiêu dùng sẽ bị "chậm trễ".
Vậy làm cách nào chúng ta có thể xử lý tin nhắn mới kịp thời và tránh CPU chạy không tải?
Để giải quyết vấn đề này, Redis cung cấp lệnh BRPOP. Lệnh BRPOP còn được gọi là chặn đọc. Khi máy khách không đọc dữ liệu hàng đợi, nó sẽ tự động chặn cho đến khi dữ liệu mới được ghi vào hàng đợi, sau đó bắt đầu đọc dữ liệu mới. So với chương trình tiêu dùng liên tục gọi chính lệnh RPOP, phương pháp này có thể tiết kiệm chi phí hoạt động của CPU. (B ở đây ám chỉ Block.).
Khi sử dụng phương pháp chặn của BRPOP để kéo tin nhắn, nó cũng hỗ trợ chuyển trong "khoảng thời gian chờ". Nếu được đặt thành 0, điều đó có nghĩa là không có thời gian chờ nào được đặt và tin nhắn sẽ không được trả lại cho đến khi có tin nhắn mới. NULL sẽ được trả về sau khoảng thời gian chờ được chỉ định.
// Mã giả while (true) { // Không chặn và chờ tin nhắn, 0 nghĩa là không đặt thời gian chờ var msg = redis.brpop("mq",0) if(msg == null) hand(msg) }
Lưu ý: Nếu thời gian chờ được đặt quá lâu và kết nối không hoạt động trong một thời gian dài, Redis Server có thể đánh giá là kết nối không hợp lệ và khi đó Redis Server sẽ buộc máy khách bị khởi động ngoại tuyến. Vì vậy, để áp dụng giải pháp này, khách hàng phải có cơ chế kết nối lại.
Không được hỗ trợ.
Không được hỗ trợ.
Tuy nhiên, khi doanh nghiệp được triển khai bằng ID duy nhất và các phương pháp khác, nó sẽ được đánh giá xem liệu nó đã được xử lý sau khi sử dụng ID hay chưa, để kết quả xử lý cho cùng một thông báo là nhất quán, đảm bảo tính bình thường.
Chỉ có phía người tiêu dùng là không bị thiệt.
Loại List cung cấp lệnh BRPOPLPUSH, cho phép chương trình tiêu dùng đọc tin nhắn từ Danh sách. Đồng thời, Redis sẽ chèn tin nhắn vào Danh sách khác (có thể gọi là Danh sách dự phòng) để lưu trữ.
Nếu chương trình tiêu dùng đọc tin nhắn nhưng không xử lý bình thường thì sau khi khởi động lại, nó có thể đọc lại tin nhắn từ Danh sách sao lưu và xử lý nó.
Đừng tích lũy.
Nếu mức tiêu thụ chậm và số lượng tin nhắn trong Danh sách tích lũy, áp lực bộ nhớ đối với redis sẽ tăng lên. Hơn nữa, bản thân List không hỗ trợ các nhóm người tiêu dùng và không thể được nhiều người tiêu dùng sử dụng.
| nhu cầu | DANH SÁCH |
|---|---|
| Đơn hàng đảm bảo dữ liệu | ủng hộ. Sử dụng LPUSH/RPOP |
| Hỗ trợ chặn và chờ kéo tin nhắn | ủng hộ. Sử dụng BRPOP |
| Hỗ trợ mô hình xuất bản/đăng ký | Không được hỗ trợ |
| Tiêu thụ lặp lại | Không được hỗ trợ. Nhưng bạn có thể tự mình triển khai một ID duy nhất trên toàn cầu |
| Tin nhắn không bị mất | Không hẳn. Phía người tiêu dùng không bị mất, BRPOPLPUSH |
| Tin nhắn chồng chất | Không được hỗ trợ. Trí nhớ tiếp tục phát triển |
Đối với các tình huống kinh doanh đơn giản, bạn có thể sử dụng list. Nhưng nếu bạn muốn có nhiều nhà sản xuất và người tiêu dùng, bạn có thể tiếp tục nhìn xuống.
Redis được thiết kế đặc biệt cho mô hình xếp hàng "Xuất bản/Đăng ký" (XUẤT BẢN/ĐĂNG KÝ).
Nó có thể giải quyết vấn đề tiêu dùng lặp đi lặp lại và cho phép nhiều nhóm kịch bản của nhà sản xuất và người tiêu dùng.
Sử dụng giải pháp Pub/Sub không chỉ hỗ trợ chặn kéo tin nhắn mà còn đáp ứng nhu cầu kinh doanh của nhiều nhóm người tiêu dùng sử dụng cùng một lô dữ liệu.
Ngoài ra, Pub/Sub còn cung cấp chế độ "đăng ký phù hợp", cho phép người tiêu dùng đăng ký "nhiều" hàng đợi mà họ muốn theo các quy tắc nhất định.
Như bạn có thể thấy, ưu điểm lớn nhất của Pub/Sub là nó hỗ trợ nhiều nhóm nhà sản xuất và người tiêu dùng xử lý tin nhắn.
Nhược điểm là: mất dữ liệu.
Pub/Sub không dựa trên bất kỳ loại dữ liệu nào, cũng như không lưu trữ dữ liệu nào (nó sẽ không được ghi vào RDB và AOF). Nó chỉ đơn giản là thiết lập một kênh chuyển tiếp và chuyển tiếp dữ liệu tuân theo các quy tắc sang đầu bên kia. được chuyển tiếp trong thời gian thực.
Nếu người tiêu dùng không bình thường, nó chỉ có thể chấp nhận tin nhắn mới khi trực tuyến trở lại. Trong khoảng thời gian này, nhà sản xuất không thể tìm thấy người tiêu dùng và sẽ loại bỏ dữ liệu. Khi sử dụng Pub/Sub, lưu ý: Consumer trước tiên phải đăng ký hàng đợi trước khi nhà sản xuất có thể xuất bản tin nhắn, nếu không tin nhắn sẽ bị mất.
Khi tin nhắn bị tồn đọng, tin nhắn có thể bị mất hoặc việc sử dụng có thể không thành công. Việc triển khai Pub/Sub là phân bổ bộ đệm cho những người tiêu dùng đã đăng ký trong bộ nhớ của máy chủ.
Các nhà sản xuất xuất bản các tin nhắn và liên tục ghi chúng vào bộ đệm. Khi các tin nhắn bị tồn đọng, bộ nhớ mà bộ đệm chiếm giữ sẽ tiếp tục tăng lên. Nếu vượt quá cấu hình bộ đệm, người tiêu dùng sẽ bị ngắt kết nối, dẫn đến không sử dụng được và mất dữ liệu.
Cấu hình mặc định của bộ đệm: client-output-buffer-limit pubsub 32mb 8mb 60. 32mb: Khi bộ đệm vượt quá 32 MB, Redis sẽ trực tiếp kick người tiêu dùng ngoại tuyến 8mb + 60: Nếu bộ đệm vượt quá 8MB và tồn tại trong 60 giây, Redis cũng sẽ đá người tiêu dùng ngoại tuyến.
Danh sách kéo dữ liệu và Pub/Sub đẩy dữ liệu.
Ưu điểm và nhược điểm của Pub/Sub: 1. Hỗ trợ xuất bản/đăng ký và hỗ trợ nhiều nhóm nhà sản xuất và người tiêu dùng xử lý tin nhắn 2. Nếu người tiêu dùng ngoại tuyến, dữ liệu sẽ bị mất 3. Tính bền vững của dữ liệu không được hỗ trợ. xuống, dữ liệu cũng sẽ bị mất 4. Khi tin nhắn tích lũy và bộ đệm tràn, người tiêu dùng sẽ buộc phải ngoại tuyến và dữ liệu sẽ bị mất.
Khi cụm Sentinel giao tiếp với phiên bản Redis, giải pháp Pub/Sub sẽ được sử dụng vì Sentinel phù hợp với kịch bản kinh doanh của nhắn tin tức thời.
Rõ ràng Pub/Sub không phải là hàng đợi tin nhắn mà chúng ta mong muốn, hãy đọc tiếp.
Luồng là loại dữ liệu được Redis thiết kế đặc biệt cho hàng đợi tin nhắn. Nó cung cấp một tập hợp lệnh hoạt động hàng đợi tin nhắn phong phú.
XADD: Chèn tin nhắn, đảm bảo trật tự và có thể tự động tạo ID duy nhất trên toàn cầu XREAD: Dùng để đọc tin nhắn, dữ liệu có thể được đọc bởi ID XREADGROUP: Đọc tin nhắn dưới dạng nhóm người tiêu dùng Tin nhắn XACK đã được đọc nhưng chưa được xác nhận bởi người tiêu dùng: được sử dụng để xác nhận với hàng đợi tin nhắn rằng quá trình xử lý tin nhắn đã hoàn tất
Thông báo đẩy của nhà sản xuất:
// * có nghĩa là để Redis tự động tạo message ID 127.0.0.1:6379> XADD queue * name zhangsan "1618469123380-0" 127.0.0.1:6379>
Người tiêu dùng kéo tin nhắn:
// Đọc 5 tin nhắn từ đầu, 0-0 nghĩa là đọc từ đầu 127.0.0.1:6379> XREAD COUNT 5 STREAMS queue 0-0 1) 1) "queue" 2) 1) 1) "1618469123380-0" 2 ) 1) "tên" 2) "trương san" 2) 1) "1618469127777-0" 2) 1) "tên" 2) "lisi"
Nếu bạn muốn tiếp tục lấy tin nhắn, bạn cần nhập ID của tin nhắn trước đó:
127.0.0.1:6379> XREAD COUNT 5 STREAM hàng đợi 1618469127777-0 (không có)
Đây là cách sản xuất và tiêu thụ Stream đơn giản nhất.
ủng hộ. XADD chèn tin nhắn để đảm bảo tính ngăn nắp.
ủng hộ. Khi đọc tin nhắn bạn chỉ cần thêm tham số BLOCK.
// BLOCK 0 có nghĩa là chặn chờ, không có thời gian chờ được đặt 127.0.0.1:6379> XREAD COUNT 5 BLOCK 0 STREAMS hàng đợi 1618469127777-0
Lúc này, người tiêu dùng sẽ chặn và đợi cho đến khi nhà sản xuất đăng tin nhắn mới trước khi quay lại.
ủng hộ. Luồng hoàn tất việc xuất bản và đăng ký thông qua các lệnh sau: XGROUP: Tạo nhóm người tiêu dùng XREADGROUP: Trong nhóm người tiêu dùng được chỉ định, cho phép người tiêu dùng lấy tin nhắn.
127.0.0.1:6379> Hàng đợi XADD * tên zhangsan "1618470740565-0" 127.0.0.1:6379> Hàng đợi XADD * tên lisi "1618470743793-0"
// Tạo nhóm người tiêu dùng 1, 0-0 nghĩa là kéo tin nhắn từ đầu 127.0.0.1:6379> XGROUP CREATE queue group1 0-0 OK // Tạo nhóm người tiêu dùng 2, 0-0 nghĩa là kéo tin nhắn từ đầu 127.0.0.1: 6379> XGROUP TẠO hàng đợi nhóm2 0-0 OK
Nhóm người tiêu dùng đầu tiên bắt đầu tiêu dùng:
// Người tiêu dùng của nhóm1 bắt đầu tiêu thụ, > nghĩa là lấy dữ liệu mới nhất 127.0.0.1:6379> XREADGROUP GROUP nhóm1 người tiêu dùng COUNT 5 hàng đợi STREAMS > 1) 1) "hàng đợi" 2) 1) 1) "1618470740565-0" 2) 1 ) "tên" 2) "trương san" 2) 1) "1618470743793-0" 2) 1) "tên" 2) "lisi"
Tương tự, nhóm người tiêu dùng thứ hai bắt đầu tiêu dùng:
// Người tiêu dùng của nhóm2 bắt đầu tiêu thụ, > có nghĩa là lấy dữ liệu mới nhất 127.0.0.1:6379> XREADGROUP GROUP nhóm2 người tiêu dùng COUNT 5 hàng đợi STREAMS > 1) 1) "hàng đợi" 2) 1) 1) "1618470740565-0" 2) 1 ) "tên" 2) "trương san" 2) 1) "1618470743793-0" 2) 1) "tên" 2) "lisi"
Chúng ta có thể thấy rằng hai nhóm người tiêu dùng này có thể lấy cùng một lô dữ liệu để xử lý.
Mục đích đăng ký đạt được bằng cách tạo ra một nhóm người tiêu dùng.
ủng hộ.
ID tin nhắn đã được sử dụng khi kéo tin nhắn ở trên để đảm bảo việc sử dụng lại, ID tin nhắn này cũng được sử dụng ở đây. Sau khi một nhóm người tiêu dùng đã xử lý tin nhắn, họ cần thực thi lệnh XACK để thông báo cho Redis. Lúc này, Redis sẽ đánh dấu tin nhắn là "quá trình xử lý đã hoàn tất".
// 1618472043089-0 tin nhắn trong nhóm1 đã được xử lý 127.0.0.1:6379> Hàng đợi XACK nhóm1 1618472043089-0
Nếu người tiêu dùng gặp sự cố bất thường, XACK chắc chắn sẽ không được gửi và Redis sẽ vẫn giữ lại thông báo này.
Sau khi nhóm người tiêu dùng này trực tuyến trở lại, Redis sẽ gửi lại dữ liệu chưa được xử lý thành công cho người tiêu dùng này. Bằng cách này, ngay cả khi người tiêu dùng có bất thường, dữ liệu sẽ không bị mất.
// Consumer trực tuyến trở lại, 0-0 nghĩa là kéo lại các tin nhắn chưa ACK 127.0.0.1:6379> XREADGROUP GROUP group1 Consumer1 COUNT 5 STREAMS queue 0-0 // Dữ liệu chưa được sử dụng thành công trước đó vẫn có thể được sử dụng lại1) 1) "hàng đợi" 2) 1) 1) "1618472043089-0" 2) 1) "tên" 2) "zhangsan" 2) 1) "1618472045158-0" 2) 1) "tên" 2) "lisi"
Stream là kiểu dữ liệu mới được thêm vào Giống như các kiểu dữ liệu khác, mọi thao tác ghi cũng sẽ được ghi vào RDB và AOF.
Chúng ta chỉ cần định cấu hình chiến lược lưu giữ lâu dài để ngay cả khi Redis ngừng hoạt động và khởi động lại, dữ liệu trong Luồng vẫn có thể được khôi phục từ RDB hoặc AOF.
Được hỗ trợ, nhưng có giới hạn độ dài.
Khi việc tích lũy tin nhắn xảy ra trong hàng đợi tin nhắn, nhìn chung chỉ có hai giải pháp: 1. Giới hạn hiện tại của nhà sản xuất: để tránh người tiêu dùng không xử lý kịp thời, dẫn đến tồn đọng tiếp tục 2. Loại bỏ tin nhắn: phần mềm trung gian loại bỏ tin nhắn cũ và chỉ giữ lại tin nhắn mới của một chiều dài cố định.
Redis áp dụng giải pháp thứ hai khi triển khai Stream.
Khi xuất bản một tin nhắn, bạn có thể chỉ định độ dài tối đa của hàng đợi để ngăn chặn tình trạng nổ bộ nhớ do tồn đọng hàng đợi.
//Độ dài hàng đợi tối đa là 10000 127.0.0.1:6379> Hàng đợi XADD MAXLEN 10000 * tên zhangsan "1618473015018-0"
Khi độ dài hàng đợi vượt quá giới hạn trên, các tin nhắn cũ sẽ bị xóa và chỉ những tin nhắn mới có độ dài cố định mới được giữ lại. Từ quan điểm này, nếu Luồng có độ dài tối đa được chỉ định khi thư bị tồn đọng thì thư vẫn có thể bị mất.
Ngoài các lệnh được giới thiệu ở trên, Stream còn hỗ trợ các lệnh như xem độ dài tin nhắn (XLEN) và xem trạng thái người tiêu dùng (XINFO).
| nhu cầu | Suối |
|---|---|
| Đơn hàng đảm bảo dữ liệu | ủng hộ |
| Hỗ trợ chặn và chờ kéo tin nhắn | ủng hộ |
| Hỗ trợ mô hình xuất bản/đăng ký | ủng hộ |
| Tiêu thụ lặp lại | ủng hộ |
| Tin nhắn không bị mất | ủng hộ |
| Tin nhắn chồng chất | ủng hộ |
Vì chức năng của nó rất mạnh mẽ, điều này có nghĩa là Redis thực sự có thể được sử dụng như một phần mềm trung gian hàng đợi tin nhắn chuyên nghiệp?
Hàng đợi tin nhắn chuyên nghiệp phải đạt được hai nhiệm vụ chính: 1. Không có tin nhắn nào bị mất; 2. Tin nhắn có thể được tích lũy;
Hàng đợi tin nhắn thực sự được chia thành ba phần: nhà sản xuất, phần mềm trung gian hàng đợi và người tiêu dùng.
Mất nhà sản xuất: 1. Tin nhắn không thể gửi đi, vì lý do mạng hoặc lý do khác và phần mềm trung gian không quay trở lại 2. Không chắc chắn việc gửi có thành công hay không: Thời gian chờ xuất bản là do lý do mạng, v.v. Dữ liệu có thể có. đã được gửi thành công nhưng phản hồi đã hết thời gian đọc.
Trong trường hợp đầu tiên, chỉ cần gửi lại. Trường hợp thứ hai, do không biết có thành công hay không nên để tránh mất mát, bạn chỉ có thể thử gửi lại cho đến khi thành công.
Các nhà sản xuất thường đặt số lần thử lại. Nếu số lần thử lại vượt quá giới hạn trên thì phải ghi lại nhật ký và gửi cảnh báo.
Có, để tránh mất mát, việc gửi đi lặp lại có thể được chấp nhận. Một số phán đoán hợp lý cần được đưa ra từ phía người tiêu dùng. Doanh nghiệp có thể cần đảm bảo tính bình thường.
Do đó, redis hoặc các hàng đợi phần mềm trung gian khác có thể đảm bảo không làm mất dữ liệu của nhà sản xuất.
Sau khi người tiêu dùng nhận được tin nhắn, nó bất ngờ gặp sự cố trước khi quá trình xử lý hoàn tất. Người tiêu dùng vẫn có thể sử dụng lại tin nhắn bị lỗi chứ? Để giải quyết vấn đề này, người tiêu dùng phải "thông báo" cho queue middleware sau khi xử lý tin nhắn, để queue middleware sẽ đánh dấu tin nhắn đã xử lý, nếu không dữ liệu vẫn sẽ được gửi đến người tiêu dùng. Giải pháp này yêu cầu sự hợp tác của người tiêu dùng và phần mềm trung gian để đảm bảo rằng các thông báo về phía người tiêu dùng không bị mất. Cho dù đó là Stream của Redis hay phần mềm trung gian hàng đợi chuyên nghiệp, chẳng hạn như RabbitMQ và Kafka, đây thực sự là cách nó được thực hiện.
Vì vậy, từ góc độ này, Redis cũng đủ điều kiện.
Chỉ cần máy khách và máy chủ hợp tác tốt với các vấn đề trên, chúng tôi có thể đảm bảo rằng cả bên sản xuất và bên tiêu dùng đều không bị mất tin nhắn.
Nhưng điều gì sẽ xảy ra nếu bản thân phần mềm trung gian của hàng đợi không đáng tin cậy?
Ở khía cạnh này, Redis thực sự không đáp ứng được yêu cầu.
Redis sẽ gây mất dữ liệu trong hai trường hợp sau.
1. Tính bền vững của AOF được cấu hình để ghi vào đĩa mỗi giây, nhưng quá trình ghi đĩa này không đồng bộ và có khả năng mất dữ liệu khi Redis ngừng hoạt động.
2. Sao chép Master-Slave cũng không đồng bộ. Khi chuyển đổi Master-Slave cũng có khả năng bị mất dữ liệu (thư viện Slave chưa hoàn thành việc đồng bộ hóa dữ liệu do thư viện Master gửi và nó được thăng cấp lên thư viện Master). ).
Dựa trên những lý do trên, chúng ta có thể thấy rằng bản thân Redis không thể đảm bảo tính toàn vẹn dữ liệu một cách nghiêm ngặt.
Khi sử dụng phần mềm trung gian hàng đợi chuyên nghiệp như RabbitMQ hoặc Kafka, một cụm thường được triển khai. Khi nhà sản xuất xuất bản một tin nhắn, phần mềm trung gian hàng đợi thường ghi "nhiều nút" để đảm bảo tính toàn vẹn của tin nhắn. Bằng cách này, ngay cả khi một trong các nút bị lỗi, dữ liệu của cụm sẽ không bị mất.
Vị trí của Redis thì khác. Nó được định vị nhiều hơn như một bộ đệm. Chắc chắn có sự khác biệt giữa hai loại ở khía cạnh này.
Dữ liệu Redis được lưu trữ trong bộ nhớ, nghĩa là một khi xảy ra tình trạng tồn đọng tin nhắn, bộ nhớ của Redis sẽ tiếp tục tăng lên nếu vượt quá giới hạn bộ nhớ của máy sẽ gặp nguy cơ OOM. Luồng của Redis cung cấp chức năng chỉ định độ dài tối đa của hàng đợi để tránh tình trạng này.
Nhưng các hàng đợi tin nhắn như Kafka và RabbitMQ thì khác. Dữ liệu của chúng sẽ được lưu trữ trên đĩa. Chi phí của đĩa nhỏ hơn nhiều so với chi phí của bộ nhớ. Khi các tin nhắn bị tồn đọng, nó sẽ chiếm nhiều dung lượng đĩa hơn so với bộ nhớ. cũng “bình tĩnh” hơn khi đối mặt với tồn đọng.
Khi sử dụng Redis làm hàng đợi, luôn có hai vấn đề: 1. Bản thân Redis có thể mất dữ liệu, 2. Đối mặt với tình trạng tồn đọng các tin nhắn, tài nguyên bộ nhớ Redis bị eo hẹp.
Nếu kịch bản kinh doanh của bạn đủ đơn giản, không nhạy cảm với việc mất dữ liệu và xác suất tồn đọng thư tương đối nhỏ thì việc sử dụng Redis làm hàng đợi là hoàn toàn ổn.
Hơn nữa, so với Kafka và RabbitMQ, Redis nhẹ hơn về mặt triển khai và vận hành.
Nếu tình huống kinh doanh của bạn rất nhạy cảm với việc mất dữ liệu và khối lượng ghi rất lớn cũng như việc tồn đọng các tin nhắn sẽ chiếm nhiều tài nguyên máy thì tôi khuyên bạn nên sử dụng phần mềm trung gian xếp hàng tin nhắn chuyên nghiệp.
Các tình huống ứng dụng: 1. Đơn hàng đã hết thời gian chờ và chưa được thanh toán nên đơn hàng sẽ bị đóng và hàng tồn kho sẽ được trả lại 2. Không có nhận xét nào tự động sau 5 ngày sau khi hoàn tất đơn hàng 3. Số lượng người dùng đồng thời. lớn nên việc gửi email và tin nhắn bị chậm trễ.
ZSET + bỏ phiếu theo lịch trình.
Phím màn hình (không khuyến khích).
Tham khảo, sao chép, nghiên cứu, trích dẫn với:
Trang web chính thức của Redis Vui lòng không phụ thuộc quá nhiều vào việc theo dõi thời gian hết hạn của Redis. Việc sử dụng Redis làm hàng đợi có thực sự phù hợp không? Kiểm tra hàng đợi tin nhắn: Có giải pháp nào cho Redis?
Cuối cùng, bài viết về chủ đề Redis - Queue này kết thúc tại đây. Nếu bạn muốn biết thêm về chủ đề Redis - Queue, vui lòng tìm kiếm các bài viết về CFSDN hoặc tiếp tục duyệt các bài viết liên quan. Hy vọng bạn sẽ ủng hộ blog của tôi trong thời gian tới! .
31
4
0
Đơn giản chỉ cần chuyển sang chủ đề. Tôi khuyên bạn nên thực hành lại quy trình xây dựng. Nếu thấy phiền phức, bạn có thể sao chép trực tiếp dự án trước đó, nhưng bạn cần sửa đổi một số thông tin trong pom.xml?
Vào ngày 10 tháng 4 năm 2020, "Ý kiến của Ban Chấp hành Trung ương Đảng Cộng sản Trung Quốc và Hội đồng Nhà nước về Xây dựng Hệ thống phân bổ và Cơ chế các yếu tố theo định hướng thị trường hoàn hảo hơn" đã chính thức được ban hành, xác lập dữ liệu là một trong năm cơ chế chính yếu tố sản xuất (đất đai, vốn, lao động và công nghệ).
Tôi là một lập trình viên xuất sắc, rất giỏi!