Một BACKEND hiểu về 4 cơ chế cách ly này trong MYSQL đồng thời CAO, vui lòng hãy nộp CV vào BANKING

Рет қаралды 9,616

Күн бұрын

Пікірлер: 20

@juhandvan 3 ай бұрын

Mục đích ra đời của phương pháp thứ 3: REPEATABLE READ. là gì vậy anh ? Em hiểu cơ chế nhưng chưa hiểu mục đích của nó để làm gì ạ ?

@nguyenminhtuan2632 6 ай бұрын

Dạ, anh có thể làm thêm video giải thích về Multi-Versioning trong mySQL sử dụng innoDB engine được không ạ ?

@anonystick 6 ай бұрын

Được em.

@quanphamanh957 3 ай бұрын

Em chuyển ngành nên chỉ học video của anh có thể xin pv được không ạ

@BuiBon-v9f 6 ай бұрын

Dạ anh ơi, em muốn hỏi về tính đồng thời cao đối với Redis trong trường hợp cụ thể như săn sale, lúc đó khả năng đọc ghi quá mức của Redis thì nó có thể chết, trong video trước anh cũng đã triển khai khoá phân tán, thì có cách nào để giảm áp lực lên Redis khi triển khai Flash sale hông a, em cảm ơn anh nhiều

@letuan5069 6 ай бұрын

thử chạy lua script trong redis chưa bạn ?

@BuiBon-v9f 6 ай бұрын

@@letuan5069dạ cảm ơn anh, để em thử

@phatvphat 6 ай бұрын

Anh cho em hỏi nếu trong giao dịch tiền bạc thì mặc định REPEATABLE-READ nó sẽ hoạt động ra sao? Có phải 2 giao dịch đồng thời đều sẽ có số tiền ban đầu như nhau và có thể dẫn đến xung đột khi UPDATE không?

@anonystick 6 ай бұрын

Chính xác. Khi về FINTECH không nên REPEATABLE.

@nguyenhoanglong9970 6 ай бұрын

Anh cho em hỏi là có lý do nào mà anh k có dùng PostgreSQL k ? Hay chỉ đơn giản là MySQL thân thuộc vs anh ?

@anonystick 6 ай бұрын

PostgreSQL hiện tại anh chưa có dịp test về performance mà chỉ nghe trên internet, Với lại MySQL đang làm rất tốt những thứ phức tạp. CHo nên anh nghĩ chưa cần phải thay đổi.

@nhatminh9193 6 ай бұрын

Anh ơi 1 năm này mongodb nó đã ra cái search vector nó khá là pro, anh có thể làm video về nó không ạ?

@anonystick 6 ай бұрын

Nhận kèo!

@balol8820 6 ай бұрын

Serializable nếu update trên hai id khác nhau thì có bị treo như ví dụ không ạ?

@LongTran-og7ji 4 ай бұрын

Lock trên row nên sẽ không bị treo nhé bạn

@kakamissyou09 3 ай бұрын

@@LongTran-og7ji treo chứ. Nó lock table lun mà.

@LongTran-og7ji 3 ай бұрын

@@kakamissyou09 InnoDb nó có row locking và next-key lock, câu hỏi kia đang là update trên 2 id khác nhau nữa thì theo bác tại sao lại là lock trên table?

@LongTran-og7ji 3 ай бұрын

@placeholder612 hợp lý, nếu Postgresql thì sẽ có Predicate lock để phát hiện conflict transactions, nếu có conflict thì transaction sẽ raise error và backend tự handle retry. Chung quy DBMS vẫn có lock table, nhưng với câu hỏi trên mà đi lock table thì performance quá tồi.