Twemproxy: sharding Redis, hash tag và lệnh không hỗ trợ

Twemproxy là proxy mỏng đứng trước nhiều máy Redis hoặc Memcached, chia khóa cho từng máy theo hàm băm. Nó không phải proxy HTTP đổi IP. ProxyVN viết bài này theo tài liệu chính thức của dự án, kèm bộ đối chiếu lệnh Redis đã chạy thật trên bảng lệnh của dự án.

Twemproxy là gì và khác proxy IP thuê ở điểm nào

Twemproxy, tên chương trình là nutcracker, do Twitter phát hành. README mô tả nó là proxy nhanh và nhẹ cho memcached và redis. Ứng dụng nói chuyện với Twemproxy bằng giao thức Redis hoặc Memcached ASCII, như với một máy chủ cache thông thường.

Phía sau, Twemproxy giữ kết nối bền tới các máy chủ cache và chia khóa cho từng máy. Nhờ đó số kết nối tới mỗi máy Redis giữ ở mức thấp, và ứng dụng không cần tự biết khóa nào nằm ở máy nào.

Không phải Redis làm hàng đợi cho proxy IP

Bài Redis quản lý proxy xoay dùng Redis như kho trạng thái: ai đang giữ IP nào, IP nào nghỉ bao lâu. Ở đó Redis là công cụ phục vụ việc quản lý proxy. Bài này khác hẳn. Twemproxy là lớp phân mảnh đứng trước Redis, và chủ đề là các lệnh Redis còn chạy được hay không sau lớp đó.

Nó cũng không phải proxy HTTP hay SOCKS5 để anh em thuê IP. Nó không đổi IP khi vào website, không có IP xoay. Định dạng chuỗi proxy trong bài định dạng proxy không liên quan tới cấu hình của nó.

Vì sao người làm thu thập dữ liệu gặp nó

Hệ thống thu thập dữ liệu lớn thường dùng Redis cho hàng đợi URL, tập URL đã thấy và bộ nhớ đệm kết quả. Khi một máy Redis không đủ, anh em chia khóa ra nhiều máy. Twemproxy là một cách làm việc đó mà không sửa ứng dụng.

Nhưng nó cắt bớt tập lệnh. Một hàng đợi dùng `BLPOP` hay một worker dùng `MULTI` sẽ hỏng ngay. Đó là lý do bài tập trung vào bảng lệnh.

Phạm vi đã thử và chưa thử

README ghi Twemproxy chạy trên Linux, BSD, macOS và SmartOS. Máy mình soạn bài chạy Windows, không có Docker, không có bản phân phối WSL và không có Redis. Mình không chạy Twemproxy.

Phần mình chạy thật là script Python đối chiếu danh sách lệnh với bảng lệnh chính thức của dự án, tải về lúc chạy. Mọi hành vi của Twemproxy trong bài là mô tả theo tài liệu. Mình đánh dấu rõ ở từng chỗ.

Một điểm cần biết trước: bản phát hành mới nhất trên GitHub là 0.5.0, ngày 13/07/2021. Dự án không ra bản mới đã hơn năm năm. Đó không phải lỗi, nhưng anh em nên tự cân nhắc khi chọn nền tảng cho hệ thống mới.

Định tuyến Redis và Memcached bằng Twemproxy: pool, hàm băm, ketama

Pool, hàm băm và ketama chọn máy Redis

Tập tin cấu hình của Twemproxy là YAML. Mỗi mục cấp một là một pool, mỗi pool có cổng lắng nghe riêng.

Các khóa cấu hình quan trọng

README của Twemproxy liệt kê các khóa. Mình rút lại những khóa dùng trong lab.

• `listen` là địa chỉ và cổng, hoặc đường dẫn socket Unix, cho pool này.
• `redis` là giá trị boolean cho biết pool nói giao thức Redis hay Memcached. Mặc định là false, tức Memcached. Quên dòng này khi dùng Redis là lỗi đầu tiên.
• `servers` là danh sách máy, dạng `địa chỉ:cổng:trọng số`, có thể thêm tên nút phía sau.
• `hash` là tên hàm băm. Mặc định `fnv1a_64`. Danh sách có `md5`, `crc16`, `crc32`, `murmur`, `jenkins` và vài hàm khác.
• `distribution` là cách chọn máy từ giá trị băm. Mặc định và được khuyên dùng là `ketama`, một cách cài đặt consistent hashing. Hai lựa chọn khác là `modula` (băm chia lấy dư theo số máy) và `random`.
• `hash_tag` là chuỗi hai ký tự, ví dụ `"{}"`, chỉ định phần nào của khóa được băm.
• `timeout` là thời gian chờ tính bằng mili giây khi kết nối hay chờ trả lời. Mặc định là chờ vô thời hạn.
• `auto_eject_hosts` quyết định có loại tạm một máy khi nó lỗi liên tiếp. Mặc định false.
• `server_retry_timeout` mặc định 30000 mili giây, và `server_failure_limit` mặc định 2.
• `server_connections` là số kết nối tối đa mở tới mỗi máy. Mặc định chỉ mở một.
• `redis_auth` là mật khẩu Twemproxy dùng để đăng nhập các máy Redis phía sau.
• `preconnect` quyết định có nối sẵn tới mọi máy khi khởi động hay không. Mặc định false.

Một pool Redis tối thiểu

lab_cache:
  listen: 127.0.0.1:22121
  redis: true
  hash: fnv1a_64
  distribution: ketama
  hash_tag: "{}"
  timeout: 400
  auto_eject_hosts: false
  servers:
    - 127.0.0.1:6380:1 node1
    - 127.0.0.1:6381:1 node2
    - 127.0.0.1:6382:1 node3

Cấu hình này gần như đúng với pool `beta` trong README: có `hash_tag`, không tự loại máy, kèm tên nút. Mình thêm `timeout: 400` theo khuyến nghị của tài liệu về thời gian chờ.

Tên nút cho consistent hashing

Tài liệu khuyến nghị dùng tên nút khi `auto_eject_hosts` bằng false. Nếu chỉ viết `host:port:weight`, khóa được ánh xạ thẳng tới bộ ba đó. Nếu thêm tên, khóa ánh xạ tới tên, rồi tên ánh xạ tới máy. Cách thứ hai cho phép dời một nút sang máy khác mà không làm xáo vòng băm.

Khi dùng tên nút, Twemproxy bỏ qua giá trị trọng số trong chuỗi. Nếu anh em trông chờ trọng số nặng nhẹ giữa các máy, hãy nhớ điều này.

Kiểm tra cú pháp trước khi chạy

Tham số dòng lệnh `-t` hoặc `--test-conf` kiểm tra tệp YAML có lỗi cú pháp không rồi thoát. README ghi rõ mục đích đó. Hãy chạy lệnh này trước mỗi lần nạp cấu hình mới.

nutcracker -t -c conf/nutcracker.yml
nutcracker -c conf/nutcracker.yml -v 6 -o /var/log/nutcracker.log

Ở lệnh thứ hai, `-v 6` đặt mức log bằng LOG_INFO. Tài liệu khuyến nghị bật mức này vì chi phí thấp, và nó ghi lại vòng đời của kết nối và sự kiện loại máy khỏi vòng băm.

Chuẩn bị lab Twemproxy: topology, phiên bản, listener, backend

Lab gồm ba máy Redis, một Twemproxy và một client.

Build từ mã nguồn

README hướng dẫn build từ bản tarball của phiên bản 0.5.0 trở lên bằng ba lệnh: `./configure`, `make`, `sudo make install`. Chế độ gỡ lỗi dùng `CFLAGS="-ggdb3 -O0" ./configure --enable-debug=full`. Nếu build từ mã nguồn kèm log và assertion, chạy thêm `autoreconf -fvi` trước.

Vì tài liệu build chỉ nhắm các hệ Unix, anh em dùng Linux hoặc container Linux. Bản phát hành duy nhất trên trang Releases là `twemproxy-0.5.0.tar.gz`, không có gói dựng sẵn.

Topology

Ba Redis nghe ở 6380, 6381, 6382 trên cùng máy, Twemproxy nghe 22121. Redis không cần cấu hình đặc biệt, không cần cluster hay sao chép. Mỗi Redis là một máy độc lập, và Twemproxy chia khóa giữa chúng.

Client dùng `redis-cli -p 22121`. Muốn đối chiếu, mở thêm kết nối thẳng tới từng cổng 6380 đến 6382 để xem khóa nằm ở đâu.

Cổng thống kê

Twemproxy mở thêm cổng thống kê, mặc định 22222, địa chỉ nghe mặc định `0.0.0.0`, tổng hợp mỗi 30 giây. Dữ liệu là JSON trả thẳng qua TCP. Tùy chọn `-s` đổi cổng, `-a` đổi địa chỉ, `-i` đổi chu kỳ. Địa chỉ mặc định nghe mọi giao diện, nên trong lab hãy đặt `-a 127.0.0.1`.

Lệnh `nutcracker --describe-stats` in mô tả mọi bộ đếm. Với pool có các đếm như `client_connections`, `server_ejects`, `forward_error`, `fragments`. Với từng máy có `server_timedout`, `requests`, `responses`, `in_queue`, `out_queue`.

Hash tag, sharding và những lệnh Twemproxy không hỗ trợ

Đây là phần quyết định ứng dụng của anh em có dùng được Twemproxy hay không.

Hash tag

Hash tag đưa hai khóa về cùng một máy

Khi không có hash tag, Twemproxy băm cả khóa. Với `hash_tag: "{}"`, chỉ phần nằm giữa hai dấu ngoặc được băm. Hai khóa `user:{user1}:ids` và `user:{user1}:tweets` cùng băm chuỗi `user1`, nên cùng rơi vào một máy. Khóa `user:user1:ids` không có dấu ngoặc, nên băm cả chuỗi và có thể rơi vào máy khác.

Hash tag là công cụ duy nhất để ép nhiều khóa về một máy. Nhiều lệnh nhiều khóa phụ thuộc vào đó.

Bảng lệnh chính thức

Tệp notes/redis.md trong repository chia lệnh theo nhóm, mỗi lệnh có cột "Supported?" với ba giá trị: Yes, No và Yes* (có điều kiện). Mình đếm bằng script: bảng có 187 dòng lệnh, trong đó 113 Yes, 17 Yes* và 57 No.

Những nhóm lệnh bị chặn đáng chú ý:

• Giao dịch: `MULTI`, `EXEC`, `DISCARD`, `WATCH`, `UNWATCH` đều No.
• Pub/Sub: `SUBSCRIBE`, `PUBLISH`, `PSUBSCRIBE` và các lệnh liên quan đều No.
• Chặn: `BLPOP`, `BRPOP`, `BRPOPLPUSH`, `BLMOVE`, `BZPOPMIN`, `BZPOPMAX` đều No.
• Duyệt khóa: `KEYS`, `SCAN`, `RANDOMKEY` đều No.
• Đổi tên khóa: `RENAME`, `RENAMENX`, `MOVE`, `MIGRATE` đều No.
• Kết nối: `AUTH`, `ECHO`, `SELECT` đều No. `PING` và `QUIT` thì Yes.
• Quản trị: `INFO`, `CONFIG GET`, `CONFIG SET`, `FLUSHALL`, `FLUSHDB`, `DBSIZE`, `MONITOR`, `TIME` đều No.

Đọc danh sách này, anh em thấy ngay hai họ ứng dụng hỏng. Một là hàng đợi dùng `BLPOP`. Hai là ứng dụng dùng `SELECT` để chia cơ sở dữ liệu logic. Twemproxy luôn tự trình bày với client là DB 0, theo tài liệu về khóa `redis_db`.

Lệnh Yes* cần cùng máy

Nhóm Yes* chạy được nhưng với điều kiện. `RPOPLPUSH`, `SINTER`, `SUNION`, `SDIFF`, `SMOVE`, `ZINTERSTORE`, `ZUNIONSTORE`, `PFMERGE` yêu cầu mọi khóa trong lệnh băm về cùng máy. Cách bảo đảm là dùng chung hash tag cho tất cả khóa.

Tài liệu nhấn mạnh Twemproxy không kiểm tra điều này. Nếu khóa nằm ở hai máy khác nhau, lệnh vẫn được chuyển đi và kết quả không có ý nghĩa. `EVAL` và `EVALSHA` cũng ở nhóm này: chỉ hỗ trợ script có ít nhất một khóa, và nếu nhiều khóa thì chúng phải cùng máy. Các lệnh `SCRIPT LOAD`, `SCRIPT EXISTS` và họ hàng đều No.

Lệnh nhiều khóa bị cắt mảnh

Với `MGET`, `MSET`, `DEL`, `UNLINK`, `EXISTS`, Twemproxy tách một lệnh thành nhiều mảnh (fragment), gửi mỗi mảnh tới đúng máy rồi ghép kết quả. Ghi chú trong bảng nói chỉ các lệnh vector hóa này cần cắt. Bộ đếm `fragments` trong thống kê cho biết số mảnh đã tạo.

Điều này có nghĩa là một `MGET` nhiều khóa không còn là một thao tác nguyên tử trên một máy. Nếu logic ứng dụng giả định đọc cùng lúc, hãy kiểm tra lại.

Lệnh chuyển tiếp ngẫu nhiên

Tài liệu ghi `COMMAND` và `LOLWUT` được chuyển tới một máy Redis bất kỳ, vì chúng không phụ thuộc trạng thái dữ liệu. `COMMAND` không được lọc, nên danh sách lệnh nó trả về không phản ánh những lệnh Twemproxy từ chối.

Cấu hình Twemproxy tối thiểu, quyền truy cập và các tuyến cần kiểm tra

Cấu hình đã nêu ở trên đủ cho lab. Phần này nói thêm về các tuyến cần kiểm tra và quyền truy cập.

Quyền truy cập

Twemproxy không có giao diện đăng nhập cho client. Bảng lệnh ghi `AUTH` là No. Khóa `redis_auth` chỉ dùng cho hướng ngược: Twemproxy đăng nhập vào máy Redis phía sau. Vậy nên bảo vệ cổng `listen` bằng tường lửa, địa chỉ nghe nội bộ hoặc socket Unix, chứ đừng trông vào mật khẩu ở phía client.

Socket Unix là lựa chọn gọn khi ứng dụng và Twemproxy cùng máy. Tài liệu cho phép khai `listen` là đường dẫn đầy đủ kèm quyền, như `/tmp/gamma 0666` trong ví dụ. Quyền 0666 cho mọi người dùng trên máy đọc ghi socket, nên hãy đặt quyền chặt hơn và chỉ cho tài khoản chạy ứng dụng.

Nếu mật khẩu được đặt trên Redis phía sau, mọi máy trong cùng pool phải dùng chung `redis_auth`. Nếu mật khẩu khác nhau giữa các máy, một pool không phục vụ được.

Ba tuyến cần kiểm tra

Tuyến thứ nhất là client tới Twemproxy tới Redis, với khóa không có hash tag. Tuyến thứ hai là khóa có hash tag, dùng để chứng minh nhiều khóa về cùng máy. Tuyến thứ ba là lệnh bị chặn, để thấy phản hồi lỗi.

redis-cli -p 22121 SET a 1
redis-cli -p 22121 SET "user:{u1}:ids" 1
redis-cli -p 22121 SET "user:{u1}:tweets" 2
redis-cli -p 22121 MGET a "user:{u1}:ids" "user:{u1}:tweets"
redis-cli -p 22121 SINTER "set:{u1}:a" "set:{u1}:b"
redis-cli -p 22121 KEYS "*"
redis-cli -p 22121 MULTI

Hai khóa có tag `{u1}` phải nằm cùng một trong ba máy. Khóa `a` có thể ở máy khác. Để chứng minh, chạy `redis-cli -p 6380 KEYS "*"` và hai cổng còn lại, rồi so. Lệnh `KEYS` qua Twemproxy, `MULTI` và vài lệnh khác nên trả lỗi hoặc đóng kết nối, vì bảng ghi No. Hình thức phản hồi cụ thể mình chưa thấy, nên anh em ghi lại ở lần chạy đầu.

Bộ đối chiếu lệnh Redis với Twemproxy đã chạy thật

15 lệnh đối chiếu: 2 chạy, 2 có điều kiện, 11 bị chặn

Trước khi chuyển ứng dụng sang Twemproxy, việc rẻ nhất là biết nó dùng những lệnh nào.

Script mình viết

`kiem_tra_lenh_twemproxy.py` tải tệp `notes/redis.md`, đọc các dòng của bảng lệnh và so danh sách lệnh anh em đưa vào. Đầu ra chia thành bốn nhóm: Yes, Yes*, No và không có trong bảng. Nó không kết nối Redis và không chạy Twemproxy.

Mình chạy với hai danh sách, lấy từ bảng lệnh Redis của dự án. Danh sách thứ nhất là ứng dụng bộ nhớ đệm đơn giản gồm `GET SET DEL MGET EXPIRE INCR HGETALL ZADD LPUSH`. Cả chín lệnh đều thuộc nhóm Yes.

Danh sách thứ hai là ứng dụng hàng đợi gồm `BLPOP LPUSH MULTI EXEC SUBSCRIBE PUBLISH SELECT AUTH KEYS SCAN INFO EVAL SINTER SCRIPT LOAD PING`.

Bảng: Script mình viết

Nhóm	Lệnh
Yes	LPUSH, PING
Yes* (cần cùng máy)	EVAL, SINTER
No	BLPOP, MULTI, EXEC, SUBSCRIBE, PUBLISH, SELECT, AUTH, KEYS, SCAN, INFO, SCRIPT LOAD

Từ 15 lệnh, chỉ 2 chạy thẳng, 2 chạy có điều kiện và 11 bị chặn. Ứng dụng hàng đợi này không dùng được Twemproxy mà không sửa mã.

Giới hạn của script

Bảng được đọc bằng biểu thức chính quy trên tệp Markdown của repository, nên nếu định dạng bảng đổi, số dòng đọc được sẽ đổi. Script chỉ biết tên lệnh. Nó không biết đối số, nên không nhận ra `EVAL` có một khóa hay nhiều khóa, và không biết ứng dụng có đặt hash tag đúng không. Với driver dùng đường ống (pipeline) hay lệnh bên trong thư viện, danh sách lệnh phải lấy từ nhật ký thật, ví dụ lệnh `MONITOR` chạy trên Redis trực tiếp một lúc.

Bảng cũng chỉ phản ánh tệp ở nhánh chính của repository tại thời điểm tải, không nói về phiên bản Redis mới hơn. Lệnh Redis thêm sau thời điểm bảng được cập nhật sẽ hiện là "không có trong bảng".

Chạy ca đúng và sai với Twemproxy, đọc stats và log

Phần này mô tả kịch bản chạy khi có lab. Mọi kết quả ở đây là theo tài liệu, chưa chạy.

Ca loại máy tự động

Đặt `auto_eject_hosts: true`, `server_failure_limit: 3`, `server_retry_timeout: 30000`, đúng ví dụ pool kháng lỗi trong tài liệu khuyến nghị. Tắt một Redis. Sau ba lỗi liên tiếp trên máy đó, Twemproxy loại nó khỏi vòng băm tới hết thời gian thử lại. Bộ đếm `server_ejects` tăng.

Hệ quả quan trọng: tài liệu nói máy bị loại khiến các khóa vốn ở máy đó rơi sang máy còn sống. Nghĩa là dữ liệu bị phân mảnh lại, và khóa cũ không còn tìm thấy ở chỗ mới.

Tài liệu cũng nói Twemproxy không tự thử lại yêu cầu. Để yêu cầu không mất khi máy bị loại, client phải tự thử lại, và số lần thử phải lớn hơn `server_failure_limit`. Nếu không, yêu cầu gặp lỗi trước khi máy bị loại sẽ không bao giờ tới máy sống.

Ca thời gian chờ

Không đặt `timeout`, Twemproxy chờ vô thời hạn. Tài liệu khuyên luôn đặt `timeout` cho mọi pool, thay vì chỉ dựa vào timeout phía client. Lý do là client hết giờ nhưng yêu cầu vẫn treo ở chặng proxy tới máy chủ. Client thử lại sẽ làm tình hình tệ hơn.

Khi hết giờ, Twemproxy trả lỗi `-ERR Connection timed out` cho Redis, hoặc `SERVER_ERROR Connection timed out` cho Memcached. Tài liệu coi mọi phản hồi dạng `-ERR` hay `SERVER_ERROR` là lỗi tạm thời, ứng viên tốt để thử lại.

Ca đọc lại giá trị vừa ghi

Mặc định `server_connections` bằng 1. Nếu đặt lớn hơn 1, ràng buộc "đọc được giá trị vừa ghi" có thể không còn đúng. Tài liệu giải thích: lệnh ghi và lệnh đọc trong cùng một pipeline có thể đi trên hai kết nối khác nhau và hoàn thành chạy đua với nhau. Nếu ứng dụng cần ràng buộc này, giữ `server_connections: 1` hoặc dùng client chỉ gửi yêu cầu đồng bộ.

Ca này khó tái hiện vì nó là chạy đua. Mình không đặt nó vào bộ ca bắt buộc, mà ghi để anh em biết trước khi tăng giá trị này vì muốn tăng thông lượng.

Khóa quá dài

Với Memcached, giao thức giới hạn khóa 250 ký tự. Với Redis không có giới hạn như vậy, nhưng Twemproxy cần khóa nằm liền trong bộ đệm mbuf, nên độ dài tối đa của khóa bị giới hạn bởi dung lượng dữ liệu của một mbuf. Mặc định mbuf là 16384 byte. Muốn khóa lớn hơn, tăng bằng tùy chọn `-m`. Ngược lại, khi phục vụ rất nhiều kết nối đồng thời, tài liệu khuyên giảm xuống còn 512 byte.

Đọc log và thống kê

Log chỉ có khi Twemproxy được build có bật log. Mặc định ghi ra stderr, hoặc ra tệp bằng `-o`. Trên tiến trình đang chạy, gửi tín hiệu SIGTTIN để tăng mức log, SIGTTOU để giảm, SIGHUP để mở lại tệp log sau khi xoay vòng.

Thống kê nằm ở cổng 22222. Dùng `nc 127.0.0.1 22222` để xem JSON. Các bộ đếm đáng theo dõi gồm `server_ejects`, `server_timedout`, `forward_error` và `in_queue`. Bài giám sát proxy bằng Prometheus và Grafana cho cách nghĩ chung về việc vẽ các bộ đếm kiểu này, dù áp dụng cho proxy IP.

Đưa Twemproxy vào hệ thống thật: hoàn nguyên, giới hạn, bảo mật

Checklist trước khi chuyển ứng dụng sang Twemproxy

Lab chạy được chưa đủ để đưa vào sản xuất.

Hoàn nguyên

Trước mỗi thay đổi, hãy giữ lại bản sao tệp cấu hình đang chạy ổn. Twemproxy đọc cấu hình lúc khởi động. Tài liệu mình đọc không nêu cách nạp lại cấu hình khi đang chạy, nên mình không khẳng định điều đó. Cách an toàn là chạy `-t` kiểm tra cú pháp, rồi khởi động bản mới trên cổng khác, chuyển ứng dụng sang, giữ bản cũ để quay lại.

Đổi số máy trong pool là thay đổi nhạy cảm. Với `ketama`, thêm hoặc bớt máy chỉ làm dời một phần khóa. Với `modula`, đổi số máy làm đổi gần như toàn bộ ánh xạ khóa, và cache coi như mất sạch. Tài liệu gọi `ketama` là mặc định và được khuyên dùng.

Giới hạn tài nguyên

`client_connections` giới hạn số kết nối client của pool, mặc định không giới hạn ngoài giới hạn hệ điều hành. `backlog` mặc định 512. Mình không đo RAM hay thông lượng nên không đưa con số riêng.

README có bảng so sánh redis-benchmark giữa kết nối thẳng và qua Twemproxy, trên phần cứng của tác giả. Số liệu ấy cho thấy độ trễ thêm của một chặng, nhưng không áp dụng cho máy anh em. Hãy tự đo với tải thật.

Cân bằng giữa phân mảnh và tính sẵn sàng

Twemproxy phân mảnh khóa, không sao chép dữ liệu. Nếu một máy Redis chết mà không có bản sao, phần khóa ở máy đó mất. Tài liệu nhắc các công cụ ngoài như smitty hay twemsentinel dùng cho chuyển đổi dự phòng, nhưng đó là dự án của bên thứ ba, mình chưa thử. Bài về HAProxy và proxy failover nói về lớp cân bằng và dự phòng ở mức mạng.

Ghi chép khi thử

Khi chạy lab thật, anh em nên lưu ba thứ: phiên bản Twemproxy và Redis, tệp cấu hình đã dùng, và máy nào giữ khóa nào sau mỗi ca. Ba thứ này đủ để người khác tái hiện kết quả mà không phải hỏi lại anh em từng bước một. Nếu thấy phản hồi khác với mô tả trong bài, hãy tin kết quả thật và cập nhật tài liệu nội bộ theo nó.

Khi nào Twemproxy chưa phải lựa chọn tốt

Nếu ứng dụng cần giao dịch, pub/sub, lệnh chặn hay `SCAN`, Twemproxy không phù hợp. Redis Cluster hoặc client biết chia khóa là các hướng khác, mỗi hướng có đánh đổi riêng mà bài này không đi sâu. Nếu chỉ cần một máy Redis, thêm Twemproxy là thêm một thành phần mà không có lợi ích.

Câu hỏi thường gặp về Twemproxy

Twemproxy có chạy trên Windows không. README liệt kê Linux, BSD, OS X và SmartOS. Trên Windows, cách thực tế là chạy trong máy ảo Linux hoặc container. Mình chưa thử.

Twemproxy có đổi IP khi vào website không. Không. Nó chia khóa cho cache, không liên quan tới IP truy cập website. Muốn đổi IP, anh em dùng proxy HTTP hoặc SOCKS5.

Tại sao `SELECT` không chạy. Bảng lệnh ghi `SELECT` là No, và Twemproxy luôn trình bày với client là DB 0. Ứng dụng cần nhiều cơ sở dữ liệu logic phải đổi sang tiền tố khóa.

Làm sao để hai khóa luôn ở cùng một máy. Dùng cùng hash tag, ví dụ `{u1}` trong tên khóa, và bật `hash_tag: "{}"` trong cấu hình pool. Twemproxy không kiểm tra thay anh em.

Dùng `ketama` hay `modula`. Tài liệu gọi `ketama` là mặc định và khuyến nghị. Với `modula`, đổi số máy làm đổi gần hết ánh xạ khóa.

Máy bị loại thì dữ liệu ra sao. Khi `auto_eject_hosts` bật, các khóa của máy đó rơi sang máy khác. Đó là phân mảnh lại, không phải sao chép. Tắt `auto_eject_hosts` nếu anh em muốn lỗi hiện rõ thay vì dữ liệu chuyển chỗ.

Twemproxy có hỗ trợ mật khẩu Redis không. Hỗ trợ ở hướng proxy tới Redis qua `redis_auth`. Ở hướng client tới proxy, `AUTH` được ghi là không hỗ trợ.

Có nên dùng cho hệ thống mới không. Dự án có bản mới nhất từ năm 2021. Hãy xem lịch sử commit và nhu cầu của mình rồi tự quyết. Bài này chỉ giúp biết nó làm gì và không làm gì.

Cần thêm IP, anh em có thể mua proxy tại ProxyVN, có proxy dân cư tĩnh Viettel, VNPT, FPT, datacenter Việt Nam và proxy xoay, hỗ trợ HTTP và SOCKS5 với tài khoản user và mật khẩu.

Twemproxy: những điều cần nhớ

Twemproxy chia khóa Redis và Memcached cho nhiều máy, chặn giao dịch, pub/sub, lệnh chặn và SCAN. Dùng hash tag cho lệnh nhiều khóa, đặt timeout, bật auto_eject_hosts thì cần client tự thử lại. Cần proxy IP ổn định cho thu thập dữ liệu, liên hệ Proxy.vn - Nhà cung cấp dịch vụ proxy chất lượng hàng đầu Việt Nam cho Twemproxy.