Đồng ý với bạn, dùng qua Nest mình thấy khá đau đầu vì import ở file module, nhiều libs dev viết kém nên imports, providers phải add tay vào tứ tung, còn cái document thì viết kiểu như không muốn viết. Dù đội dev của Nest có cố gắng tạo ra CLI để bù cho việc import tay vào module cha nhưng mà thực sự nhìn cái đống code generate ra rồi dùng libs bên thứ 3 vào import muốn nhảy lầu 🤣
Mình không thích NestJS vì xử lý import và dùng decorator quá lung tung, chính NestJS mình mới thấy nửa mùa khi cố gắng dùng Typescript nhưng thực sự không thể biết được chính xác DI đã được tiêm vào object ở file module hay chưa, phải debug bằng runtime rồi đọc lỗi sau đó mới vào tận module để import, điều này chưa bao giờ thấy xuất hiện ở những ngôn ngữ type mạnh như C# hoặc Java. Nói chung dùng cho những dự án đông người thì khá ổn, còn về dự án muốn tối ưu cực mạnh thì nên dùng đúng 1 thread OOP mà làm, còn Decorators chỉ nên được sử dụng cho những tác vụ validate properties trong class hoặc log hệ thống để làm thống kê.
Anh cho em hỏi phần bài lab của Cluster-IP thì em đang làm khác đi 1 chút:
Config của ReplicaSet em định nghĩa containerPort = 1111
Config của Service port của service = 6379 (Mục đích của em là để connect được pod helllo-redis của anh) và targetPort = 1111 (Mục đích là connect với port của các container nằm trong ReplicaSet ở bên trên)
Nhưng khi em kiểm tra log của pod (hello-redis) thì nó throw errorr. Em đang không biết mình đang hiểu sai chổ nào, mong anh giải đáp ạ.
nếu chỉ sử dụng như 1 field bth và đánh index thì key của row đó vẫn dùng id tăng dần thì chúng ta lại dính lại vòng lặp ID generator tuần tự.
thuật snowflake hay sonyflake được thiết kế để nó làm khóa chính của bảng.
có 1 vài lý do để mình hoặc bạn có thể tin rằng id đó là duy nhất
Trong Snowflale được chia thành 4 phần trong đó có timestamp được lưu dưới dạng milliseconds, vậy nếu 1 millisecond bạn chỉ nhận 1 request, tức 1000 reuquest/s thì khả năng trùng đã ~0
worker_id giả sử lượng request của bạn lớn(request lớn vậy chắc chắn cũng 5-7 sever cùng chịu tải) thì worker_id sẽ là phần làm id của bạn giảm khả năng trùng xuống rất nhiều.
trong trường hợp bạn có 1 datacenter và 5 worker. thì số id có thể tạo ra cho bạn trong 1 milliseconds là 4096 * 5 = 20480 (đây là lượng request siêu siêu lớn)
mysql không make sure cho bạn, Snowflale sẽ make sure cho bạn trong trường hợp lượng request bạn đang xử lý nhỏ hơn con số mình đưa ra.
Với các hệ thống phân tán đủ lớn sẽ có thêm nhiều datacenter đặt tại nhiều nơi/quốc gia, điều này làm tăng thêm khả năng tạo ra các ID duy nhất lên nhiều lần.
mình nghĩ không giải quyết đc vấn đề, vì tốc độ chạy của 1 request sẽ phụ thuộc vào nhiều yếu tố như băng thông, cache, ... và không bất biến. Ví dụ server A lấy dữ liệu xong cache lại, lần đầu chậm nhưng các lần sau sẽ nhanh, kiểu vậy
THẢO LUẬN
này em phải xem Redis Container nó mở port nào nữa, mặc định Redis sử dụng port 6379 nên em chỉ định
containerPortlà 1111 nó sẽ không chạyHay
@nguyentuan239 Ngon đấy! 👍️
Nhớ theo dõi nhé! Phần 3 mình sẽ ra chế độ beatup 😁
Hay đấy bạn. Ngày trước mình cũng một thời pro beatup
)
Đồng ý với bạn, dùng qua Nest mình thấy khá đau đầu vì import ở file module, nhiều libs dev viết kém nên imports, providers phải add tay vào tứ tung, còn cái document thì viết kiểu như không muốn viết. Dù đội dev của Nest có cố gắng tạo ra CLI để bù cho việc import tay vào module cha nhưng mà thực sự nhìn cái đống code generate ra rồi dùng libs bên thứ 3 vào import muốn nhảy lầu 🤣
Mình không thích NestJS vì xử lý import và dùng decorator quá lung tung, chính NestJS mình mới thấy nửa mùa khi cố gắng dùng Typescript nhưng thực sự không thể biết được chính xác DI đã được tiêm vào object ở file module hay chưa, phải debug bằng runtime rồi đọc lỗi sau đó mới vào tận module để import, điều này chưa bao giờ thấy xuất hiện ở những ngôn ngữ type mạnh như C# hoặc Java. Nói chung dùng cho những dự án đông người thì khá ổn, còn về dự án muốn tối ưu cực mạnh thì nên dùng đúng 1 thread OOP mà làm, còn Decorators chỉ nên được sử dụng cho những tác vụ validate properties trong class hoặc log hệ thống để làm thống kê.
Anh cho em hỏi phần bài lab của Cluster-IP thì em đang làm khác đi 1 chút:
nếu chỉ sử dụng như 1 field bth và đánh index thì key của row đó vẫn dùng id tăng dần thì chúng ta lại dính lại vòng lặp ID generator tuần tự. thuật snowflake hay sonyflake được thiết kế để nó làm khóa chính của bảng. có 1 vài lý do để mình hoặc bạn có thể tin rằng id đó là duy nhất
trong trường hợp bạn có 1 datacenter và 5 worker. thì số id có thể tạo ra cho bạn trong 1 milliseconds là 4096 * 5 = 20480 (đây là lượng request siêu siêu lớn)
mysql không make sure cho bạn, Snowflale sẽ make sure cho bạn trong trường hợp lượng request bạn đang xử lý nhỏ hơn con số mình đưa ra.
Với các hệ thống phân tán đủ lớn sẽ có thêm nhiều datacenter đặt tại nhiều nơi/quốc gia, điều này làm tăng thêm khả năng tạo ra các ID duy nhất lên nhiều lần.
@NgocPH Bác check tin nhắn giúp tui nhé
độ dịch chuyển lệch trái = 3 "Wlfk vr fxd fklhx fdr Cdwd yd Odylooh" ai giải hộ mình với ạ
@haialison bạn check thử có vào nhầm bên OpenAI ko á, bạn vào link này thử nè https://chat.openai.com/chat
à là do mình vào platform nên mới hiển thị như vậy, bh vào chat.openai.com thì vào đc rồi, cảm ơn bạn nhiều nhé.
@NgocPH
nó chỉ có mấy cái này thôi, chứ k có new chat
@haialison bạn chọn new chat rồi cứ nhắn yêu cầu bình thường thôi à, mình cũng chọn về công nghệ nhưng kêu nó làm thơ, làm nhạc vẫn được hết à
@NgocPH cho mình hỏi là khi chọn mục đích dùng thì chọn gì để nói chuyện bình thường với nó được nhỉ 🥲, mình lỡ ấn chọn cho coding rồi..
https://laraveldaily.com/post/process-big-db-table-with-chunk-method ở đây có giải thích nè
tks
tks
mình nghĩ không giải quyết đc vấn đề, vì tốc độ chạy của 1 request sẽ phụ thuộc vào nhiều yếu tố như băng thông, cache, ... và không bất biến. Ví dụ server A lấy dữ liệu xong cache lại, lần đầu chậm nhưng các lần sau sẽ nhanh, kiểu vậy