redis sharding, pipelining và round-trips

Question

Giả sử trong ứng dụng web của bạn, bạn cần phải thực hiện một số cuộc gọi redis để hiển thị một trang, như, nhận được một loạt các băm người dùng. Để tăng tốc độ này, bạn có thể gói các lệnh redis của bạn trong phần MULTI/EXEC, do đó sử dụng pipelining để tránh phải thực hiện nhiều chuyến đi khứ hồi. Nhưng bạn cũng muốn phân tích dữ liệu của mình, bởi vì bạn có rất nhiều dữ liệu và/hoặc bạn muốn phân phối các bài viết. Sau đó pipelining sẽ không hoạt động, bởi vì các khóa khác nhau có khả năng sống trên các nút khác nhau, trừ khi bạn có ý tưởng rõ ràng về bố cục dữ liệu của ứng dụng và phân đoạn dựa trên vai trò thay vì sử dụng hàm băm. Vì vậy, các phương pháp hay nhất để phân đoạn dữ liệu trên các máy chủ khác nhau mà không ảnh hưởng đến hiệu suất quá nhiều do nhiều máy chủ được liên hệ để hoàn thành công việc "độc đáo về khái niệm" là gì? Tôi tin rằng câu trả lời phụ thuộc vào ứng dụng web đang phát triển, và cuối cùng tôi sẽ chạy một số thử nghiệm, nhưng sẽ rất hữu ích nếu biết người khác đã đối phó với sự cân bằng mà tôi đã đề cập đến như thế nào.

Answer 1

MULTI/EXEC và pipelining là hai thứ khác nhau. Bạn có thể làm MULTI/EXEC mà không cần pipelining và ngược lại.

Nếu bạn muốn phân đoạn và đường ống cùng một lúc, bạn cần nhóm các hoạt động thành đường ống cho mỗi trường hợp Redis, sau đó sử dụng pipelining cho từng trường hợp.

Đây là một ví dụ đơn giản sử dụng Ruby: https://gist.github.com/2587593

Một cách để cải thiện hơn nữa hiệu suất là để parallelize lưu lượng trên các trường hợp Redis khi hoạt động đã được nhóm (tức là bạn nhóm các hoạt động, bạn gửi cho tất cả trường hợp song song, bạn chờ câu trả lời từ tất cả các trường hợp).

Điều này phức tạp hơn một chút, vì yêu cầu khách hàng không chặn không đồng bộ. Để đạt hiệu suất tối đa, C/C++ nên được sử dụng ở phía máy khách. Điều này có thể dễ dàng thực hiện bằng cách sử dụng hiredis + vòng lặp sự kiện mà bạn chọn.