thảo luận Hệ thống có nhiều TPS nhất đã từng làm

• Tối ưu code: viết đơn giản, gọn
• Tối ưu DB: đánh index, partition dữ liệu
• Sử dụng Load balancing để share tải
• Healcheck hệ thống, cái này khó phết, vì qua Load balacing nếu service connect trực tiếp thì LB sẽ biết được service lỗi khi nào để ko route qua, nhưng nếu qua một service khác thì LB sẽ ko phát hiện được
• Áp dụng ELK để monitor và theo dõi log.

docker28 said:

Nghe có vẻ giống hệ thống chứng khoán trước mình từng làm

Click to expand...

quangtung2912 said:

TPS là cả read lẫn write hay chỉ write thôi vậy thớt

Click to expand...

asklyking said:

1 ngày tầm đó thì có vẻ giống ck chắc rồi.

Click to expand...

step321 said:

Write tôi bác, read chưa tính, thường read bằng 1.2 -->2 lần write

Click to expand...

ngocquocktqd said:

mình làm hệ thống cấp data 1 ngày tầm 10triệu req

via theNEXTvoz for iPhone

Click to expand...

freedom.9 said:

Nếu write thì có cần tính consistency hay chỉ cần eventually consistency là được bác?
Việc kiểm tra health check mình nghĩ nếu giao tiếp phần write qua kafka, phần read thì dùng 1 internal db thì mình ko nghĩ sẽ cần thiết phải communicate directly từ service này qua service kia. Hay ý bác là gọi qua 1 third party service nào đó.
Bác cho mình tech stacks cty bác mình nghiên cứu thử cho vui
via theNEXTvoz for iPhone

Click to expand...

step321 said:

Java spring boot bác ạ, có queue mà chỉ dùng khi put file lớn, còn bt vẫn là all api.

Click to expand...

step321 said:

Bác chia sẻ thêm kn thiết kế và tối ưu hệ thống với.

Click to expand...

freedom.9 said:

Nếu thế thì system design của bác ko có gì đặc biệt nhỉ. Vẫn chạy scale ngon thì chắc ko vấn đề gì.
Thường để scale lên được thì phải xài Kafka, Sql, Cassandra hoặc Mongo db rồi tìm cách chuyển dữ liệu từ SQL qua Cassandra, tăng read performance thì phải xài thêm Redis các thứ nữa tuỳ bài toán. Vẫn ko hiểu tại sao lại ko health check được services vì nếu call rest API thì request nó vẫn phải đi qua load balancer mà.
Monitoring thì mình thấy xịn nhất vẫn là xài datadog cơ bản là hơi tốn kém

Click to expand...

step321 said:

Mình lập thớt để anh em trao đổi kinh nghiệm về các hệ thống có TPS lớn nhất mà Anh/Em đã từng làm, từ đó rút ra kinh nghiệm cho công việc sau này.

Mình trước: hệ thống có TPS lớn nhất mà minh đã từng làm và hiện vẫn đang tunring, monitor hàng ngày là có TPS 2 chiều khoảng 20 TPS, mỗi ngày khoang 2.5 triệu giao dịch, vẫn đang tăng và hiện hệ thống vẫn đáp ứng được yêu cầu.

Kinh nghiệm mà mình thấy gồm các bước tối ưu:

• Tối ưu code: viết đơn giản, gọn
• Tối ưu DB: đánh index, partition dữ liệu
• Sử dụng Load balancing để share tải
• Healcheck hệ thống, cái này khó phết, vì qua Load balacing nếu service connect trực tiếp thì LB sẽ biết được service lỗi khi nào để ko route qua, nhưng nếu qua một service khác thì LB sẽ ko phát hiện được
• Áp dụng ELK để monitor và theo dõi log.

Click to expand...

WasupMoFucker said:

TPS khủng mà nhà giàu server to thì chưa chắc ngon bằng app đơn giản nhưng code sạch + optimized
Nên là cũng khó mà so sánh ai tay to hơn ai

Click to expand...

akiradang said:

cty cũ em xài gần như full combo bác đề cập. Có kafka để scale, redis dùng caching, postgres lưu transaction và có kết hợp cả mongodb để giảm tải + lưu data config với business logic. Nhưng chắc do code lởm quá chứ user chỉ có vài ngàn mà hệ thống cũng chết lên chết xuống


Ý bác là service A call qua B thì đi qua LB, còn service A call qua service C xong vòng lại service B thì không à?

Click to expand...

chimsedinang_no1 said:

Thường đánh giá độ khủng của hệ thống là tính trên s, chứ còn 2.5 tr/ ngày thì con số nói chung vẫn là khá bé, ko đáng gì cả.

Click to expand...