@hoangkim1982

Hay. Bổ ích ạ

Gút chóp em

Làm cách nào để đảm bảo tính atomic trong trường hợp này, nếu 1 trong các batch write xảy ra lỗi anh nhỉ?

Lưu ý khi sử dụng LISTAGG với dữ liệu lớn, kết quả trả về chỉ limit ở 4000 characters

@tinhtn89 bạn thêm distinct hoặc group by vào như này

SELECT distinct a.* FROM students a inner join students b on b.toan = a.toan and b.ly = a.ly and b.hoa = a.hoa and b.id <> a.id

hoặc dùng where exists như này

SELECT * FROM students a where exists ( select 1 from students b where b.toan = a.toan and b.ly = a.ly and b.hoa = a.hoa and a.id <> b.id )

@maitrungduc1410 Mình đã fix được rồi bạn nhé, rất cám ơn bạn đã nhiệt tình support ạ !

@Midoriniji Cách này nếu có 2 kết quả thì đúng, từ 2 trở lên sẽ bị nhân lên rất nhiều. VD: có 8 người giống điểm nhau thì nó sẽ list kết quả ra 8x7=56 bản ghi.

Điểm 10 chất lượng. Gần bằng anh Hoàng rồi =))

var count = 0.obs thì count nó không có kiểu dữ liệu là int mà sẽ là RxInt, chỉ có count.value mới mang kiểu dữ liệu int. Nên muốn làm gì với cái biến thì phải làm trên value của nó.

@maitrungduc1410 Mình có chạy" curl localhost:6379 " trong workspace báo lỗi kết nối như này

@Mario sorry bạn hôm qua mình nhìn nhầm, lỗi của bạn là do laravel echo server ko connect được tới redis, mà laravel echo server đang được chạy ở môi trường gốc (ko trong docker), dựa vào cấu hình file laravel-echo-server.json thì host đang để là null tức là laravel echo server mặc định nó sẽ gọi vào localhost:6001 để connect tới Redis (gọi vào máy gốc ở cổng 6001).

Bạn check lại cho mình, ở máy gốc, bạn chạy curl localhost:6379 xem có trả về như sau ko?

Nếu trả về "could not resolve host", "connection refused" hoặc treo terminal thì cái Redis từ Laradock kia đang có vấn đề ko truy cập được từ máy gốc

7.laravel-echo-server.json

4.composer.json 5. package.json 6.js/bootstrap.js

@maitrungduc1410 Các file mình config như này, bạn xem qua giúp mình với ạ!

1. Hiện tại mình dùng laradock và có chạy Redis
2. file .env
3. file config/database.php

Chính xác nếu đi sâu vào chi tiết thì 1 core có rất nhiều register. Nhưng toàn bộ các register đó sẽ phục vụ cho core đó. Với các Software developer/engineer hiểu đến vậy là đủ. Chắc bạn là Computer Scientist thì sẽ cần quan tâm nhiều và sâu hơn. Bản thân mình là SE nên hiểu đến bây nhiêu thôi, có gì bạn chỉ giáo và bổ sung thêm nhé. Thanks

Yep chính xác có rất nhiều trường hợp xảy ra. Nhưng suy đến gốc rễ cần hiểu trong trường hợp đấy thread vì sao bị ngừng. Tất cả đều quy về 2 lý do chính: 1 là cache coherency. 2 là switch context. Bản thân việc dừng vì IO hay vì 1 lí do gì thread đó đều được back về queue, nó là context switch. Còn việc fetch data từ memory là cache coherency.

@tinhtn89 Ừm hôm trước mình cũng nghĩ tới case này, mình định comment là bạn đổi qua thành nối các số điểm thành một chuỗi để tránh trường hợp đấy. Các của bác @tinhtn89 cũng là một hướng. Bạn tham khảo nhé.

Bài này hình như có mấy chỗ sai, xin link gốc để kiểm chứng:

• 2 trường hợp để dùng HT: theo tôi hiểu là lúc nào thread bị ngừng vì lí do nào đấy, bất kể lí do nào (IO, lấy data từ RAM,...), "execution unit" nhảy sang 1 thread khác được chuẩn bị sẵn để tranh thủ chạy luôn. Tức là có rất nhiều trường hợp để HT xảy ra chứ không thấy nguồn nào nhắc rõ chỉ có 2 truowfg hợp kia.
• Số register: mỗi nhân có nhiều register lắm kể cả từ thời cụ cố 8086.

Bài viết chi tiết ghê, mà cái title bài viết không bao quát lắm nên giờ mới tìm được!