Bài viết được sự cho phép của tác giả Nguyễn Hữu Đồng
Vào một ngày đẹp trời, đang ngồi code lan man mình nhận được thông báo từ xếp, một con service tracking của một project cũ đang gây nghẽn database, chuyện là cty đó đang ăn nên làm ra traffic vô site tăng gấp 15 lần, user tương tác nhiều dẫn đến các con service khác cũng tải nhiều hơn, db thì càng ngày càng bị hấp diêm nhiều hơn, ko chỉ đến từ còn service tracking mà còn đến từ nhiều con khác.
Tracking thì ngày trước mình code theo mô hình đơn giản, Client gọi API, đẩy message vào 1 cái queue, có tầm 100 con consumer ngồi hốt message ra process rồi ghi vô database.
Nhưng đến nước này thì chỉ có thể giảm tải cho database bằng cách giảm số lượng con consumer xuống, hạn chế tải đồng thời cho database. Trước kia code vô nhân đạo nên mình ko handle chuyện cần restart lại App thì mới update config. Tranh thủ lúc đang nhàn rỗi, mấy dự án đang ngồi chờ chốt requirement nên tranh thủ update sửa cho em nó.
Nhu cầu cần thiết lúc này là
- Chỉ cần update file config là app tự động update số consumer
- Khi deploy new code thì phải graceful shutdown, chờ mỗi consumer xử lí xong message và cho em nó nghỉ ngơi.
Viper có sẵn tính năng watch
config file nên mình sẽ dùng luôn
Khi config có sự thay đổi thì nếu là thay đổi giá trị số consumer thì mình tiến hành chạy function ResizeConsumerCount
để update lại số lượng consumer
Để quản lí mỗi consumer
sẽ thì mình có cái slice
mỗi phần từ có type như sau
type ConsumerRoutine struct {
Id int // ID của consumer
Exit chan bool // Channel để nhận lệnh exit
Channel *amqp.Channel // AMQP channel
Delivery <-chan amqp.Delivery // AMQP delivery chan,để nhận message từ queue
Done chan bool // Channel báo cáo lên thằng quản lí tao xong hết rồi, chuẩn bị thoát
}
Mỗi consumer
khi chạy sẽ ôm cái biến này để giao tiếp với thằng quản lí.
Khởi tạo consumer
và các thần phần cần thiết khác.
Bắt đầu tạo consumer
, mỗi consumer
sẽ được chạy trong 1 goroutine
và update tình trạng vào cái biến mà nó đươc giao
Mỗi khi chạy một con consumer
mới thì nó sẽ lắng nghe lệnh exit
từ bên ngoài thông qua channel m.Exit
, nhận message
từ queue qua channel m.Delivery
. Có message
thì sẽ xử lí khi nào xong thì nghe tiếp.
Đến lượt function thay đổi số lượng consumer
Và function main nơi mà mọi thứ bắt đầu.
Dưới dây là file config.
amqp_url: "amqp://admin:admin@172.31.39.18:5672"
queue_name: "queue:demo"
consumer_count: 10
Build và chạy demo nào
➜ resizeConsumer go build && ./rc
Consumer : 0 started Exit pointer val = 0xc00019a018
Consumer : 1 started Exit pointer val = 0xc00019a058
SIGNAL : urgent I/O condition
SIGNAL : urgent I/O condition
SIGNAL : urgent I/O condition
SIGNAL : urgent I/O condition
SIGNAL : urgent I/O condition
Sửa config thì 4 con consumer
amqp_url: "amqp://admin:admin@172.31.39.18:5672"
queue_name: "queue:demo"
consumer_count: 4
Thấy update trong console
Scale down xuống 1
amqp_url: "amqp://admin:admin@172.31.39.18:5672"
queue_name: "queue:demo"
consumer_count: 1
Output
Thử tắt luôn con app
SIGNAL : urgent I/O condition
SIGNAL : urgent I/O condition
SIGNAL : hangup
shuting down consumer : 0
Exit Chan Pointer = 0xc00019a018
have to exit now
Consumer 0 ended
Trước mắt thì có vẻ nó hoạt động ổn, mình sẽ test cẩn thận trước khi cho lên production. Lâu quá không viết bài nên mình tranh thủ luôn.
File code mình để ở đây,các bạn thấy hay thì start cho mình với nha https://gist.github.com/dongnguyenltqb/5a4ed0e2dc7d156e3fe6d8dfd064faff
Cảm ơn các bạn đã ghé và đọc bài viết của mình, hihi
Bài viết gốc được đăng tải tại dongnguyenltqb.medium.com
Có thể bạn quan tâm:
- Tất tần tật về cuộc đời, con đường lập nghiệp và thành công của Elon Musk
- “Chuyện thường ở huyện” tại ZALORA
- Chuyện bi kịch của công ty code outsourcing
Xem thêm Việc làm Developer hấp dẫn trên TopDev