thảo luận [Chuyện trò linh tinh - Box CNTT]

proxyy · 14/7/23

Raiha173 đã nói:
Mình cũng làm microservices mà nghe bạn trình bày thấy lùng bùng lỗ tai quá =]]]

như bác trên nói thì về cơ bản bottleneck là nằm ở db, mà trên aws ko scale horizontal đc nên chung quy lại phải xử lý đống message kia hợp lý ở application thôi

GeniVN · 14/7/23

bestlife đã nói:
Nghe câu chuyện RDS aws scale éo nổi thì nếu mình chưa từng trải qua thì cũng lùng bùng thôi . Trải nghiệm cả

hệ thống của bác hiện tại là đến khoảng bn user hay connection là bị bottleneck đấy, nghe sợ vãi nhái :eek:

nivnemo · 14/7/23

proxyy đã nói:
như bác trên nói thì về cơ bản bottleneck là nằm ở db, mà trên aws ko scale horizontal đc nên chung quy lại phải xử lý đống message kia hợp lý ở application thôi

lùng bùng vì nghe stress db đòi scale out services.

xử lý dễ mà.

đặt 1 msg broker ( kafka) trước service. consume xử lý với tốc độ phù hợp db tránh stress thôi.

kafka -> service [ rate limiter/ circuit breaker -> processing]

rate limiter điều tiết tốc độ consume, fixed or dynamic tuỳ. https://resilience4j.readme.io/docs/ratelimiter

hoặc dùng circuit breaker đóng mở, điều chỉnh đầu consume https://resilience4j.readme.io/docs/circuitbreaker

mấy cái này kinh điển mà, đặt biệc là usecase bigdata/AI, call external hoặc call AI model những cái long response đều bị phải giới giạn số lượng request, phải set timeout. ko thì chết cả thằng gọi và thằng bị gọi.

bestlife · 14/7/23

proxyy đã nói:
như bác trên nói thì về cơ bản bottleneck là nằm ở db, mà trên aws ko scale horizontal đc nên chung quy lại phải xử lý đống message kia hợp lý ở application thôi

Châm ngôn là thà để Service tắt thở chứ không để DB tèo vì xử lý đống hổ lốn log liếc ... khi DB tèo nó kinh dị lắm .

GeniVN đã nói:
hệ thống của bác hiện tại là đến khoảng bn user hay connection là bị bottleneck đấy, nghe sợ vãi nhái

Em ko phải devops nên không nắm rõ , nhưng DB service mình handle tăng vài trăm m record sau tầm 1 ngày high peak . Còn nói về connection thì phải nói đến cách xài transactions như thế nào nữa . Mà cái này mình không nắm số liệu và cũng không ước tính được

bestlife · 14/7/23

nivnemo đã nói:
lùng bùng vì nghe stress db đòi scale out services.

xử lý dễ mà.

đặt 1 msg broker ( kafka) trước service. consume xử lý với tốc độ phù hợp db tránh stress thôi.

kafka -> service [ rate limiter/ circuit breaker -> processing]

rate limiter điều tiết tốc độ consume, fixed or dynamic tuỳ. https://resilience4j.readme.io/docs/ratelimiter

hoặc dùng circuit breaker đóng mở, điều chỉnh đầu consume https://resilience4j.readme.io/docs/circuitbreaker

mấy cái này kinh điển mà, đặt biệc là usecase bigdata/AI, call external hoặc call AI model những cái long response đều bị phải giới giạn số lượng request, phải set timeout. ko thì chết cả thằng gọi và thằng bị gọi.

rate phù hợp là phù hợp ntn á bác

) . Phù hợp thằng đằng sau thì chết thằng đằng trước . Căn bản là lượng rate limit của thằng này sẽ làm ảnh hưởng tới rate limit của thằng khác và đầu với cuối là client ( để clients lăn ra chết cũng là 1 cách nhưng ko hay lắm =]]) .Trongcase này thì scale out service không phải là cách. Cách tạm thời là tắt bớt functionđể giảm rate , và long-term là viết lại từ từ

Raiha173 · 14/7/23

bestlife đã nói:
Nghe câu chuyện RDS aws scale éo nổi thì nếu mình chưa từng trải qua thì cũng lùng bùng thôi . Trải nghiệm cả

Thế thay vì chấp nhân eventual consistency thì ko chịu, sao lại đi ngắt service vậy bồ ?

nivnemo · 14/7/23

bestlife đã nói:
Phù hợp là phù hợp ntn á bác ) . Phù hợp thằng đằng sau thì chết thằng đằng trước . Căn bản là lượng rate limit của thằng này sẽ làm ảnh hưởng tới rate limit của thằng khác và đầu với cuối là client ( để clients lăn ra chết cũng là 1 cách nhưng ko hay lắm =]])

dùng kafka là để decouple service, tránh stress khi high traffic. chết thế vẹo nào được.

lý do người làm miệng chai nhỏ vì sợ uống nhiều quá nghẹn

) bóp cổ chai vừa sức rồi uống.

rds cty tôi vẫn serving 40tr users trên đó. này chốt vấn đề nằm ở thiết kế chưa tốt thôi chứ ko phải là microservice có vấn đề so với monolithic hay là aws ko đủ capacity

bestlife · 14/7/23

Raiha173 đã nói:
Thế thay vì chấp nhân eventual consistency thì ko chịu, sao lại đi ngắt service vậy bồ ?

Đầu và cuối là client . Kiểu luồng không đi đâu được nữa thì cũng chết cái services của mình thôi auto là sẽ chết thằng cuối nếu thả cửa , còn chọn chết thằng nào dễ khắc phục nhất thì là giải pháp ít tệ hơn .

GeniVN · 14/7/23

Raiha173 đã nói:
Thế thay vì chấp nhân eventual consistency thì ko chịu, sao lại đi ngắt service vậy bồ ?

sau 1 hồi hiểu chuyện thì tóm tắt lại là bác này set autoscale trên aws theo lượng request hoặc cpu load, user nhảy vào, tăng lượng load, cùng lúc đó DB bị quá tải, request ở service bị đứng, cùng lúc user nhảy tiếp vào nên load k giảm dc, cứ thế mà tăng nên nó đẻ thêm 1 loạt service, rồi cứ như thế DB lại 1 đống request vào, quá tải.

nên là tắt bớt service đi thì ai may lắm thì request dc xử lý thành công, ai đen lắm thì bị hang :beat_shot:

circuit breaker nó sinh ra để phục vụ mấy thứ này mà k dùng nhỉ. Không thì CQRS, 1 DB chuyên write, vài DB chuyên read, thế cho đỡ tải vậy

bestlife · 14/7/23

nivnemo đã nói:
dùng kafka là để decouple service, tránh stress khi high traffic. chết thế vẹo nào được.

lý do người làm miệng chai nhỏ vì sợ uống nhiều quá nghẹn ) bóp cổ chai vừa sức rồi uống.

rds cty tôi vẫn serving 40tr users trên đó. này chốt vấn đề nằm ở thiết kế chưa tốt thôi chứ ko phải là microservice có vấn đề so với monolithic hay là aws ko đủ capacity

Thì mình đã bảo rồi á , cái thằng design microservices lên title - sửa sai trên tiền của công ty mà . phải fail như thế tầm 2-3 lần may ra ổn áp tí

Ah mà có cái này nưa , Mono anh làm sai thì chi phí đập đi xây lại nó đỡ hơn khi anh làm microservice sai nhiều lắm , vì tính scalable của microservice nên khi anh thấy nó sai thì

. Còn những hạn chế khi sai của mono nó sẽ xuất hiện sớm hơn

GeniVN · 14/7/23

nivnemo đã nói:
dùng kafka là để decouple service, tránh stress khi high traffic. chết thế vẹo nào được.

lý do người làm miệng chai nhỏ vì sợ uống nhiều quá nghẹn ) bóp cổ chai vừa sức rồi uống.

rds cty tôi vẫn serving 40tr users trên đó. này chốt vấn đề nằm ở thiết kế chưa tốt thôi chứ ko phải là microservice có vấn đề so với monolithic hay là aws ko đủ capacity

đặt message queue đằng trc thì service này trở thành async đúng k bác

midnight_sun · 14/7/23

GeniVN đã nói:
sau 1 hồi hiểu chuyện thì tóm tắt lại là bác này set autoscale trên aws theo lượng request hoặc cpu load, user nhảy vào, tăng lượng load, cùng lúc đó DB bị quá tải, request ở service bị đứng, cùng lúc user nhảy tiếp vào nên load k giảm dc, cứ thế mà tăng nên nó đẻ thêm 1 loạt service, rồi cứ như thế DB lại 1 đống request vào, quá tải.

nên là tắt bớt service đi thì ai may lắm thì request dc xử lý thành công, ai đen lắm thì bị hang

circuit breaker nó sinh ra để phục vụ mấy thứ này mà k dùng nhỉ. Không thì CQRS, 1 DB chuyên write, vài DB chuyên read, thế cho đỡ tải vậy

ciỉcuit breaker cx chỉ là trả về lỗi, thế còn đống message lỗi thì tính thế nào ? theo context ở đây là hệ thống đột ngột tăng tải chứ ko phải đều, vậy effort cho cqrs lớn không ? nếu hệ thống tải cao vậy , chứng tỏ write vào cx rất nhiều, vậy replica đồng bộ trễ thế nào, chấp nhận đc ko :LOL:

ko có context cụ thể thì rất khó nói, nhưng phần lớn phải xử lý ở application để tránh request lên db

GeniVN · 14/7/23

midnight_sun đã nói:
ciỉcuit breaker cx chỉ là trả về lỗi, thế còn đống message lỗi thì tính thế nào ? theo context ở đây là hệ thống đột ngột tăng tải chứ ko phải đều, vậy effort cho cqrs lớn không ? nếu hệ thống tải cao vậy , chứng tỏ write vào cx rất nhiều, vậy replica đồng bộ trễ thế nào, chấp nhận đc ko ko có context cụ thể thì rất khó nói, nhưng phần lớn phải xử lý ở application để tránh request lên db

thấy bác ý nói mấy còm trước thì có vẻ là caching chưa tốt hay gì đó thì phải

dhuyan · 14/7/23

Cái compiler của em nó hơi dị hợm sao ấy các bác, code C mà compile mãi không được, cứ lỗi kiểu thế này

Trong khi mấy cái IDE khác như C-Free hay Dev C++ với Visual thì chạy ngon lành, không biết có phải do cái Compiler không hay sao
Version của em đây các bác

P.s: À quên gửi thêm các bác Code, tại chưa biết cách highlight nên các bác thông cảm giúp ạ

#include <stdio.h>
void swappointe(int* x, int* y) {
int temp = *x;
*x = *y;
*y = temp;
}
void bubblesortc(int n,int a[]) {
int i,j;
for (i = 0; i < n-1; i++) {
for (j = 0; j < n - i - 1; j++) {
if (a[j] > a[j+1]) {
swappointe(&a[j], &a[j+1]);
}
}
}
}
void print(int n, int a[]) {
int i;
for (i = 0; i < n; i++) {
printf("%d ", a);
}
}
int main()
{
int n;
scanf("%d", &n);
int a[10000];
int i;
for (i = 0; i < n; i++)
{
scanf("%d", &a);
}
bubblesortc(n,a);
print(n,a);
}

nivnemo · 14/7/23

GeniVN đã nói:
đặt message queue đằng trc thì service này trở thành async đúng k bác

đơn giản thì cứ async với kafka.
thích request reply thì rabbitmq nhưng phức tạp để nắm concept vì đa phần ngta dùng pubsub ít dùng rpc
https://www.rabbitmq.com/tutorials/tutorial-six-python.html
https://www.enterpriseintegrationpatterns.com/patterns/messaging/RequestReply.html

midnight_sun · 14/7/23

GeniVN đã nói:
thấy bác ý nói mấy còm trước thì có vẻ là caching chưa tốt hay gì đó thì phải

cache cũng là bài toán khó

khá là khoai khi tải lớn, hàng đống thứ xuất hiện :eek:

đợi cao nhân

GeniVN · 14/7/23

dhuyan đã nói:
Cái compiler của em nó hơi dị hợm sao ấy các bác, code C mà compile mãi không được, cứ lỗi kiểu thế này
Xem tệp đính kèm 1955052
Trong khi mấy cái IDE khác như C-Free hay Dev C++ với Visual thì chạy ngon lành, không biết có phải do cái Compiler không hay sao
Version của em đây các bácXem tệp đính kèm 1955063

lỗi dòng 31 show dòng 1 rồi ai giúp bác dc

bestlife · 14/7/23

midnight_sun đã nói:
ciỉcuit breaker cx chỉ là trả về lỗi, thế còn đống message lỗi thì tính thế nào ? theo context ở đây là hệ thống đột ngột tăng tải chứ ko phải đều, vậy effort cho cqrs lớn không ? nếu hệ thống tải cao vậy , chứng tỏ write vào cx rất nhiều, vậy replica đồng bộ trễ thế nào, chấp nhận đc ko ko có context cụ thể thì rất khó nói, nhưng phần lớn phải xử lý ở application để tránh request lên db

Giải pháp căn cơ là viết lại , vừa theo hướng paralelism vừa thiết kế lại DB sao cho có thể dễ dàng chuyển hướng request sang cho các DB replica . Một quá trình gian khổ đầy mùi tiền cháy

dhuyan · 14/7/23

GeniVN đã nói:
lỗi dòng 31 show dòng 1 rồi ai giúp bác dc

#include <stdio.h>
void swappointe(int* x, int* y) { //để dùng thuật toán phải dùng pointer ở đây
int temp = *x;
*x = *y;
*y = temp;
}
void bubblesortc(int n,int a[]) {
int i,j;
for (i = 0; i < n-1; i++) {
for (j = 0; j < n - i - 1; j++) {
if (a[j] > a[j+1]) {
swappointe(&a[j], &a[j+1]); //áp dụng tại đây bằng pointer
}
}
}
}
void print(int n, int a[]) {
int i;
for (i = 0; i < n; i++) {
printf("%d ", a);
}
}
int main()
{
int n;
scanf("%d", &n);
int a[10000];
int i;
for (i = 0; i < n; i++)
{
scanf("%d", &a);
}
bubblesortc(n,a);
print(n,a);
}

Đây bác ơi

midnight_sun · 14/7/23

bestlife đã nói:
Giải pháp căn cơ là viết lại , vừa theo hướng paralelism vừa thiết kế lại DB sao cho có thể dễ dàng chuyển hướng request sang cho các DB replica . Một quá trình gian khổ đầy mùi tiền cháy

cty mất tiền để mình lên title

thảo luận [Chuyện trò linh tinh - Box CNTT]

Senior Member

Senior Member

Senior Member

Member

Member

Member

Senior Member

Member

Senior Member

Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Member

Senior Member

Senior Member

Chủ đề tương tự

Thống kê chủ đề

Chia sẻ trang này