Ccu Là Gì

     

Truyền thuyết kể rằng, vào một trong những ngày nhà nhật đẹp trời, Minh Monmen đùng một cái nảy ra ý tưởng phát minh sẽ tuyệt ho cụ nào nếu mình dựng một mẫu dashboard để kiểm soát CCU của hệ thống theo thời gian thực. Một ý tưởng vô thuộc fancy ví như không nói về việc vì sao lại đề xuất bày vẽ làm mọi thứ mà tương đối nhiều thằng khác ĐÃ LÀM RỒILÀM NGON HƠN như Google Analytics, Firebase Analytics,... Toàn bộ việc của bọn họ cần có tác dụng chỉ là cắn nó vào và gần như thứ vẫn sẵn sàng.

Bạn đang xem: Ccu là gì

*

But no, vốn là 1 người sẵn tính đa nghi, mình thiếu tín nhiệm tưởng lắm vào những công cụ, và chỉ còn coi GA các kiểu là 1 trong loại tham chiếu thôi. Và quan trọng đặc biệt hơn, mình đề nghị hoàn toàn kiểm soát điều hành được con số mà mình chế tạo ra, hiểu nó gồm có sai số gì, nó có ý nghĩa thế nào, tại sao nó lại như vậy,... Thay vị nhắm mắt chấp nhận với một con số vô năng làm sao đó với tự hỏi bạn dạng thân về chân thành và ý nghĩa thật sự của chúng.

Don"t Reinvent The Wheel, Unless You Plan on Learning More About Wheels

Đây là tiêu đề 1 nội dung bài viết mình gọi được trên codinghorror.com về vấn đề không sáng tạo lại bánh xe pháo khi những người dân khác đã triển khai nó tốt nhất có thể rồi. Vậy nên nếu như khách hàng là 1 coder thuần túy cùng không thân thương tới bí khuất phía sau những nhỏ số, chúng ta cũng có thể bỏ đi, cũng chính vì mọi việc phía dưới đây mình làm hầu như là reinvent the wheel

First things first

Trước khi trở về câu truyện xe cộ pháo, xin dành riêng 1 phút để lưu niệm sự hiện hữu của tác giả Minh Monmen, người tuy vậy thực hiện code chỉ trong một ngày nhưng lại lại mất tới 5 ngày nhằm ghi chép lại quy trình khám phá của chính bản thân mình trên tuyến đường đến với những tri thức (cũ). Nghề nghiệp hay chứng trạng sức khỏe, hôn nhân, giới tính của người sáng tác thì nguyễn y vân nên sẽ không được nói tiếp sinh hoạt đây.

Chắc chắn bài viết này sẽ tương đối dài với có khi còn phải bóc tách ra làm cho mấy phần khác nhau, đề nghị để cho chúng ta có thêm động lực thì mình vẫn tổng kết trước 1 số điều mà mình đã học được sau một ngày cặm cụi thiết kế hệ thống đo CCU này:

Hiểu được đo lường và thống kê CCU rất khó khăn (of course).Có thời cơ thực hành 2 yếu đuối tố mà lại mình ấp ôm từ lâu: siêu nhanh cùng siêu thực (tức là không thực tế =))).Thuật toán đếm ngay sát đúng siêu nhanh siêu nhẹ: HyperloglogIn-memory caching (kiểu nghiêm túc)Batch processing (kiểu xịn xò)Sử dụng tài nguyên đúng cách (kiểu ngày tiết kiệm một cách tởm lợm)Cuối thuộc là kết luận: công nghệ KHÔNG có tác dụng ứng dụng của doanh nghiệp chạy nhanh hơn. BẠN mới là người làm điều đó....

Và rất nhiều điều khác mà lại mình không chỉ học được để gia công hệ thống này, ngoài ra để vận dụng cho tương đối nhiều bài toán khác mà tôi cũng đang đau đầu. Gồm như vậy mới biết Thiết kế lại mẫu bánh xe góp mình ko những có thể bước đi xe, mà còn làm xe có thể bước đi mình nữa.

Còn đây là những kỹ năng và kiến thức bạn cần chuẩn bị để tiếp cận với nội dung bài viết này:

CCUGolang (vì đa số implement thực hiện golang cần hiểu rõ thì sẽ giỏi hơn)Time series data: tài liệu chuỗi thời gianProbabilistic data: tài liệu ước lượngRedisPrometheus, grafana (dùng để thu thập dữ liệu và màn trình diễn đồ thị)Lòng gan góc và say đắm học hỏi (đây là thứ quan trọng nhất)

Tạm thế, nhào vô.

Mấy dòng kiến thức và kỹ năng cơ bản

Nếu đã bắt tay bắt chân vào làm cho web, tiện ích thì vớ nhiên ai cũng sẽ tối thiểu 1 lần được nghe cho tới CCU, thương hiệu tường call là kon ku, xuất xắc Concurrent Users, tức là số user đồng thời đối với một hệ thống. Định nghĩa thì nó chỉ nôm mãng cầu và dễ dàng như vầy.

*

Định nghĩa thì đơn giản và dễ dàng như vậy tuy vậy tính CCU cầm nào, cùng CCU có ý nghĩa sâu sắc ra sao với các bạn lại lại một câu chuyện trọn vẹn khác. Không có một công thức đúng chuẩn nào có thể áp dụng cho toàn bộ các hệ thống cũng chính vì mỗi biện pháp đo CCU lại cho chính mình 1 ý nghĩa sâu sắc khác nhau. Ví dụ:

Với các hệ thống thời gian thực như game, chat,... Và các user mở 1 connection dài lâu tới hệ thống như socket,... Thì CCU rất có thể được đo bằng phương pháp đếm số lượng connection tới server tại 1 thời điểm. Con số này rất có thể dùng để cho chính mình biết khả năng chịu mua của hệ thống, đo lường giới hạn, lên plan phần cứng,...Với các khối hệ thống web thông thường không sử dụng connection lâu hơn kiểu website tin tức, web phân phối hàng,... Thì CCU có thể được đo bằng cách đếm số lượng client request tới hệ thống trong 1 khoảng tầm thời gian. Con số này cũng thể hiện 1 phần lượng traffic mà bạn phải đáp ứng, tuy vậy tùy vào từng hệ thống ví dụ thì nó rất cần được kết hợp với số request được tạo tới hệ thống, tính chất từng request,... Thì chúng ta mới có cái nhìn đúng đắn hệ thống của mình.

Trong nội dung bài viết này, mình đang đề cập tới thứ hạng tính CCU cho đa phần các khối hệ thống web, app bây giờ là không thực hiện connection vĩnh viễn mà nhờ vào HTTP request của user.

Làm sao nhằm tự tính được CCU

Thông thường với các khối hệ thống analytic bình thường bạn sẽ dễ dàng quan sát và theo dõi được những chỉ số như DAU, MAU, toàn bô request trong 1 khoảng thời gian,... Và bạn hoàn toàn rất có thể dùng những chỉ số này để ước lượng CCU. Tuy vậy những con số này chỉ dừng lại ở nấc ước lượng. Chúng ta cũng có thể biết một ngày bạn tất cả 100K active user, nhưng lại số user này đâu có phân bố đồng đều? CCU của công ty khi đó hoàn toàn có thể chỉ tập trung vào 1 số thời điểm nóng mà thôi.

Và tất yếu là không phải bạn cứ mong mỏi tự tính CCU là rất có thể tính được đâu nhé. Hệ thống của các bạn phải thỏa mãn nhu cầu được đầy đủ 1 số đk ở cả phía client và server.

Client

Để rất có thể đo đếm được CCU thì client buộc phải làm một chiếc gì đó nhằm phía vps ghi nhận người tiêu dùng hiện tại vẫn active. Đó có thể là:

1 request khởi tạo nên sessionhoặc 1 request ping (ví dụ 1 phút lại ping server 1 lần)hoặc 1 request thực hiện 1 action nào kia như đọc, ghi dữ liệuCao cung cấp hơn là client từ bỏ ghi nhận thời gian user còn trên phầm mềm hay website (mà hoàn toàn có thể gửi sau tới server)...

Cơ chế phổ biến nhất và chính xác nhất thường được các loại app, web áp dụng là tạo ra 1 request ping riêng biệt tới server. Request này hoàn toàn có thể chỉ có ý nghĩa sâu sắc ping, cũng có thể chứa thêm nhiều thông tin được đóng gói khác. Nhưng đặc biệt quan trọng là nó được client hotline để báo mang đến server biết là user đang active bên trên app.

Request ping rất có thể được call định kỳ 10s, 20s, 60s tốt vài phút 1 lần tùy vào điểm lưu ý phiên thao tác làm việc của từng app.

Server

Có 2 cách đo đạc CCU phía server:

1 là tracking đơn nhất request ping. Trường hợp client đã cung cấp ping cho tới server định kỳ thì việc duy độc nhất vô nhị phía server yêu cầu làm chính là theo dõi request này.2 là lúc request ping siêng biệt ko khả dụng, thì cần có 1 lớp middleware để can thiệp vào các endpoint (hoặc đa phần endpoint) của hệ thống. Đây chỉ là phương pháp để khắc phục vấn đề client không tồn tại request ping chăm biệt, sẽ tạo nên ra nhiều sai số.

Bởi vì chưng ứng dụng của chính bản thân mình chưa cung cấp ping request, nên tôi đã xem xét và sử dụng cách thứ 2 sau khi nhận thấy kiến trúc khối hệ thống của mình phù hợp với giải pháp làm này.

Khó khăn chồng chất

Vạn sự bắt đầu nan, gian nan bước đầu nản. Sau khi bắt tay vào triển khai thì mình đã vấp đề xuất những trở ngại cả về khía cạnh số liệu và bao gồm cả mặt công nghệ như sau:

Xác định 1 CCU

Trông vậy mà đây lại là 1 câu hỏi rất cạnh tranh trả lời. Bao giờ thì chúng ta tính 1 CCU? Đó liệu có phải là khi có một user nào kia login vào website của bạn? tốt là tính cả user không đăng nhập? Vậy 1 user sử dụng 2 tab thì tính là mấy CCU? Hay thậm chí là là những request trường đoản cú bot google, facebook, mặt thứ 3,... Vào khối hệ thống cũng tính 1 CCU?

Lúc làm new thấy việc làm sao để xác định 1 CCU thôi cũng confuse rồi. Cùng lại 1 lần tiếp nữa là câu hỏi này cũng không có đáp án cơ mà việc trả lời ra sao trọn vẹn tùy nằm trong vào hệ thống của bạn có cung cấp không, giả định của người sử dụng về business và bí quyết bạn chấp nhận con số kết quả.

Bởi vị mình ko control được phần tin tức của client, vì vậy mình đã gật đầu đồng ý sử dụng những thông tin mà mình tất cả sẵn về 1 client trong từng request sau:

User ID: đã đạt được từ session/token của userClient IP: có được từ tầng proxy/gateway mặt ngoàiUser Agent: đã đạt được từ request header

Sau khi phối hợp 3 tin tức này lại, mình bao gồm được một cách định danh 1 CCU gần đúng.

Tại sao lại gần đúng? cũng chính vì sẽ có nhiều case 1 client gọi request tất cả token/không token, hoặc 1 client mở các tab không giống nhau, hoặc 1 IP chứa được nhiều client riêng rẽ biệt, hoặc các client tất cả chung user-agent...

1 CCU tồn tại trong bao lâu

1 CCU được ghi nhận sẽ tồn trên trong bao lâu?

Đó là câu hỏi bọn họ phải vấn đáp tiếp theo đối với các hệ thống không có connection lâu dài. User chỉ hệ trọng với hệ thống của họ qua những request riêng biệt lẻ, bởi vậy CCU chỉ có ý nghĩa khi chúng ta gắn nó với 1 khoảng thời hạn nào đó. Ví dụ: Trong 1 phút, số bạn cùng truy vấn vào hệ thống là 1000 người - tức là trong 1 phút đã gồm 1000 user khác nhau truy cập vào hệ thống.

Việc lựa chọn timeframe là 1 trong phút, 3 phút tuyệt 10s, 20s,... Nhờ vào hoàn toàn vào cách các bạn hiểu về hệ thống của mình. Ví dụ như với các hệ thống có ảnh hưởng qua request với gia tốc lớn thì timeframe sẽ bớt và ngược lại.

Ở đây mình tư tưởng hệ thống của chính bản thân mình gồm 3 mức: (cái này trọn vẹn là bởi vì mình từ bỏ phịa ra cùng không dựa trên 1 giáo lý nào cả bắt buộc chỉ mang tính chất tham khảo cho các bạn)

Mức PEAK: Là mức thời gian bé dại nhất (sử dụng có tác dụng mức time base nhằm đếm). Mình mang theo cực hiếm khoảng thời gian dài nhất giữa 2 request từ bỏ client. Có ý nghĩa liên quan tới số request trong 1 thời điểm peak xuất phát từ bao nhiêu client với được điện thoại tư vấn là Peak CCU. Ví dụ như app của mình định kỳ 1 phút lại call 1 request nào đấy tới server thì thời gian dài nhất giữa 2 request của client sẽ là một phút. Tuy vậy con số này có thể không đúng chuẩn khi không xuất hiện thêm những request định kỳ, hoặc client cách xử trí 1 tác vụ nào này mà KHÔNG CẦN gọi tới server.Mức SESSION: Là mức thời gian trung bình. Mình đem theo quý hiếm quanh ngưỡng thời gian trung bình 1 session của user. Số lượng này có ý nghĩa xem xét trong khoảng thời gian 1 session thì có bao nhiêu user sẽ xuất hiện. Mình gọi số lượng này là Session CCU. Thông thường thì số lượng này sẽ phản ánh đúng chuẩn CCU hơn khi nó tổng quan cả hồ hết user đã truy cập vào ứng dụng nhưng không tạo ra tác vụ nào tương quan tới server hoặc không được trình bày qua CCU thời điểm. Ví dụ như app của bản thân mình có thời lượng Time On App vừa phải là 5 phút thì mình vẫn lấy 5 phút để triển khai mức thời hạn đo Session CCUMức LIMIT: Là mức thời hạn dài duy nhất còn chú ý để tính CCU. Mức thời gian này thường được linh động tùy theo yêu cầu, tuy nhiên mình hay đặt ở tại mức 3~>6 lần Mức SESSION. Mục tiêu là xem xét lưu lượt truy cập vào hệ thống một cách tổng quát lác trong time frame đủ lâu năm để đánh giá chất lượnggiới hạn của các chiến dịch push hấp dẫn người truy nã cập. Ví dụ sử dụng 2 lần peak CCU liên tục thì liệu lần peak sau để giúp đỡ hệ thống tất cả bao nhiêu traffic mới hay chỉ toàn những traffic cũ? Khoảng thời gian này cũng tránh việc dài quá do nó có khả năng sẽ bị pha loãng và làm mượt số trong thời gian dài. Mình thường lựa chọn khoảng thời gian từ 15~>30 phút đến mức time LIMIT và gọi số lượng này là Limit CCU

*

Đếm unique CCU

Sau lúc đã bao gồm cách định danh 1 CCU và thời hạn tính CCU rồi, vậy ta làm phương pháp nào nhằm đếm unique CCU khoảng thời gian đó? Đếm chất lượng với số ít rất có thể là bài toán đối kháng giản, tuy nhiên khi số request lên tới mức hàng chục, hàng trăm ngàn ngàn request trong một khoảng thời gian ngắn thì để kiếm được số quality CCU trong số ấy lại chưa hẳn bài toán thuận lợi và nhanh chóng.

Ý tưởng đầu tiên nảy cho trong đầu khi cồn tới vấn đề này chính là sử dụng redis set. Redis Set là một kiểu tài liệu của Redis được cho phép lưu trữ 1 mảng ko lặp lại những phần tử. Ta rất có thể dễ dàng thêm bộ phận và đếm số bộ phận của 1 phối với những command có độ phức hợp O(1).

Thế nhưng thực hiện Redis Set cùng với dạng dữ liệu string như trên có nhiều nhược điểm:

Tốc độ union thấp (độ tinh vi O(n) cùng với n là số bộ phận của số đông tập hợp). Điều này khiến quá trình đo lường và tính toán cho các khoảng thời gian to hơn chậm hơn không ít (ví dụ tính số unique CCU trong 5 phút bằng cách kết thích hợp 5 key CCU của từng phút)Sử dụng rất nhiều ram do dữ liệu được lưu bên dưới dạng string set. Tuy nhiên ta hoàn toàn có thể tiết kiệm bằng phương pháp convert lại giá trị user_id-client_ip-user_agent thành chuỗi hash ngắn hơn, nhưng con số ram cần thiết để tàng trữ data đến CCU vẫn hết sức lớn.

Xem thêm: Sai Lầm Cần Tránh Khi Sử Dụng Dầu Ô Liu Có Chiên Được Không, 3 Lầm Tưởng Dinh Dưỡng Về Dầu Ô Liu

May mắn thay, nếu như bạn đã đọc nội dung bài viết trước của chính mình về Analytic cho những người nông dân: việc đếm số thì tôi đã có nhắc 1 thuật toán sinh ra để xử lý quá trình này. Đó chính là Hyperloglog.

Hyperloglog là thuật toán giám sát và đo lường gần đúng những giá trị khác biệt trong tập hợp, thuật toán này có độ chính xác cao nhưng mà vẫn giữ được dung lượng dữ liệu dịu nhàng, hỗ trợ nhiều operation liên quan tới đếm phần tử trong 1 hoặc những tập hợp. Và đặc biệt nhất là nó khôn cùng nhanh. Superfast nếu chúng ta tổ chức tài liệu hợp lý.

Nhắc lại nhẹ 1 chút kỹ năng từ nội dung bài viết trước. Cụ thể về hyperloglog các chúng ta có thể google thêm nhé. Còn tại đây tạm thời biết vậy đã. Mình hoàn toàn có thể lưu lại dữ liệu CCU đúng đắn đến từng phút vào 1 khối hệ thống vài chục triệu request từng ngày chỉ cách 10MB ram.

Tích phù hợp với các hệ thống sẵn có

Đây là phần kha khá khoai sắn khi trong 1 thời gian ngắn (1 ngày) nhằm mình có thể tích vừa lòng được vấn đề đếm CCU vào hệ thống vốn đã tinh vi hiện tại. Để cho đơn giản và dễ dàng thì mình rất có thể mô tả hệ thống của chính bản thân mình như sau:

*

Giờ mình đang can thiệp vào lớp middleware nhằm can thiệp vào các request. Việc này chứa đựng nhiều rủi ro liên quan tới performance của khối hệ thống vì middleware là lớp tác động tới phần nhiều request từ client. Và thực tế khi thực hiện thì tôi đã test được performance của tầng middleware của bản thân mình giảm 1 nửa.

Một điểm thuận tiện không hề nhẹ là bên tôi đã có sẵn khối hệ thống monitor bằng Prometheus + Grafana. Thế nên việc của mình bây giờ chỉ tất cả việc thu thập dữ liệu tự middleware với export tài liệu ra Prometheus là hoàn toàn có thể xem chart được bên trên Grafana rồi.

Bắt tay vào thực hiện

Nói dông dài như vậy là để chúng ta hiểu được bản chất của việc solve problem vào lập trình. Thời gian ta mất để tiến hành giải 1 câu hỏi thì rất cấp tốc (như mình chỉ cần 1 ngày), nhưng thời hạn ta mất để sở hữu đủ kiến thức xử lý bài toán ấy thì tương đối nhiều chút nào. Toàn bộ những kiến thức trên bản thân đã mất không ít tháng tiến hành các dự án liên quan tiền tới tracking, analytic, xây dựng kiến trúc hệ thống, monitoring,... Mới gồm được. Tôi đã rất cố gắng chắt thanh lọc để nội dung bài viết có thể súc tích và dễ nắm bắt nhất gồm thể. Các bạn hãy liên tiếp theo dõi nhé.

Action plan

Đây là đều step mình đã làm để thu thập dữ liệu:

Khi có 1 request tới hệ thống, tạo thành định danh CCU bởi việc phối kết hợp thông tin: user_id-client_ip-user_agent.Để có 1 cái nhìn sâu rộng về chỉ số CCU, mình parse user-agent để dìm diện thứ mà người tiêu dùng sử dụng. Cụ thể là phân nhiều loại sơ cỗ client thành ios, android, web_pc, web_mobile, other.Tạo ra 1 cỗ key bên trên redis tương ứng với Mức PEAK, ở đó là từng phút nhằm lưu hyperloglog, ta gọi là bucket. Mỗi nhiều loại client sẽ có 1 bucket riêng.

Hết phần data collector. Tiếp phần data exporter.

Định kỳ Prometheus sẽ call tới endpoint của data exporter để đưa metrics.

Hết phần data exporter. Sau cùng là cần sử dụng Grafana để vẽ chart. điều này easy vượt thôi không nói =)))

Chấp nhận 1 user bao gồm sai số

Oops, trong quy trình run thử mình phát hiện ra có tương đối nhiều các trường vừa lòng gây sai số cho bạn khi định danh 1 CCU:

Các request từ mặt thứ 3.Các request từ là 1 client nhưng mà tới public API với private API sẽ khác biệt về vấn đề chứa hay là không chứa token.Các request từ là một user login nhiều tài khoản với các định danh tương đương nhau....

Rất những thứ làm tác động tới việc khẳng định 1 request có được xem như là từ 1 CCU new không. Bởi vì vậy để khắc phục hạn chế này thì bản thân đã bóc thành 2 bộ chỉ số cá biệt là:

CCU đo bởi unique user (chỉ thực hiện logged-in user với định danh là user_id để đếm)CCU đo bởi unique session (sử dụng định danh IP + user-agent + user_id để đếm)

Nhờ gồm 2 chỉ số này, bản thân có một chiếc nhìn tổng thể và đúng đắn hơn về lượng user trong hệ thống, cả về khía cạnh số user (chính xác hơn nhưng mà thiếu guest) và session (kém đúng đắn hơn nhưng bao quát hơn)

Chấp dấn cả hệ thống có không đúng số

Sự hy sinh tiếp theo là về tính chuẩn xác của dữ liệu. Như tôi đã đề cập nghỉ ngơi trên, giả dụ tính CCU bởi Redis Set thì sẽ mang lại số đúng mực hơn. Tuy nhiên để tiết kiệm bộ nhớ, tương tự như tăng vận tốc trong câu hỏi union giữa những bucket thì mình đã gật đầu đồng ý sử dụng Redis Hyperloglog nhằm tính toán.

Với xác suất sai số khá thấp (Parse user-agent nhằm phân nhiều loại requestCall PFADD gấp đôi để thêm định danh vào bucket tương ứng.

Mặc dù câu hỏi parse user-agent và điện thoại tư vấn redis được chạy hoàn toàn async, có nghĩa là phản hồi lại đến user xong xuôi mới thực hiện, tuy nhiên công dụng benchmark middleware của chính bản thân mình đã sụt sút như sau:

------ Before implement ------Requests per second: 17332.91 <#/sec> (mean)Time per request: 5.515 (mean)------ After implement ------Requests per second: 7644.02 <#/sec> (mean)Time per request: 10.027 (mean)Đó quả là một sự quyết tử hơi bự đúng không? hy sinh 1 nửa performance chỉ để ship hàng việc đo đạc. Vị vậy cần mình không gật đầu đồng ý mà tiếp tục tìm phương pháp tối ưu thêm. Sau quá trình test đi kiểm tra lại vài ba tiếng đồng hồ (vụ buổi tối ưu này bắt đầu lâu này) thì mình đã tìm ra thủ phạm khiến cho ứng dụng của chính bản thân mình phải quyết tử nhiều performance như vậy:

Việc parse user-agent để phân một số loại request thường hơi trễ do phải kiểm tra qua nhiều một số loại regex không giống nhau. (~1ms/op)Call PFADD tuy nhiên có độ phức hợp O(1) và đã áp dụng redis pipeline (có tác dụng như bulk command) cơ mà vẫn tiêu tốn không ít tài nguyên với network. Thậm chí ảnh hưởng cả tới vận tốc của operation chủ yếu (cũng sử dụng redis)

Giờ hãy thuộc phân tích xem chúng ta có thể làm gì với 2 sự việc này.

Vấn đề đầu tiên là nâng cao tốc độ của câu hỏi parse user-agent. Xuất phát từ các việc user agent của phầm mềm hay web là lặp lại giữa những request của một user, thậm chí là giữa các user tất cả thiết bị kiểu như nhau. Thế nên mình đang nghĩ tới chiến thuật cache in-memory, tức là dùng những biện pháp lưu trữ biến toàn bộ để cache lại tác dụng parse user agent.

Tất nhiên là bản thân không cám hấp mà đi tự suy nghĩ ra trò cache in-memory này. Trước giờ mình chỉ quen với sử dụng redis như một lớp cache. Hiện thời đến cả redis còn đang chậm chạp vãi xoài thì đành nên kiếm biện pháp khác. Thật tình cờ trong 1 buổi sáng sớm lướt tin tức nơi nào đó thì mình đã đọc được 2 bài blog về những thư viện in-memory cache của Golang: The State of Caching in Go cùng Introducing Ristretto: A High-Performance Go Cache. Vậy là mình ra quyết định sử dụng ristretto. Quá trình benchmark của mình đều cho biết thêm mức độ áp dụng RAM tại mức thấp và tốc độ phản hồi ấn tượng. Done 1 việc.

Vấn đề sản phẩm 2 là nâng cao luồng ghi tin tức vào redis bởi PFADD command. Với vấn đề mỗi request tới hệ thống lại phải gọi 2 command bên trên thì tài năng connection cho tới redis làm cho chậm hệ thống đã xảy ra. Mình có đi research không ít chỗ, rồi cả những list awesome này nọ tuy vậy cũng không nghĩ ra phương pháp gì khả dĩ. Tiếp nối mình tạm bợ gác này lại để đi kiếm hiểu sự việc khác trước.

Nhưng đúng khi mình đang mày mò về năng lực thread-safe của tủ sách redis trên golang thì gồm 1 bình luận trong issue sẽ khai sáng mình: https://github.com/go-redis/redis/issues/166#issuecomment-149360999.

Ý tưởng ở đây là sử dụng cơ chế y hệt như buffer / flush nhằm xử lý. Mà lại ở đó là sử dụng 1 thư viện khôn xiết là lâu đời và còn được archive luôn của facebook là Muster để xử lý internal batching. Có nghĩa là những request tới redis sẽ tiến hành mình push vào 1 cái batch nội cỗ process. Định kỳ 1s hoặc 10000 request thì mình sẽ flush loại batch nội bộ trên xuống redis bởi redis pipeline. Việc này tiết kiệm được rất siêu nhiều tài nguyên và tránh làm nghẽn client redis của mình.

Wow, quả là một trong phát kiến quý giá tới mức sững sờ. Tôi đã thử implement dòng thư viện bên trên và đây là kết quả:

------ Before implement ------Requests per second: 17332.91 <#/sec> (mean)Time per request: 5.515 (mean)------ After implement #1 ------Requests per second: 7644.02 <#/sec> (mean)Time per request: 10.027 (mean)------ After implement #2 ------Requests per second: 16592.69 <#/sec> (mean)Time per request: 6.027 (mean)Tôi sẽ để đây và không nói gì cả.

Thành quả

Bỏ qua phần râu ria liên quan tới vấn đề mình viết dòng data exporter hay làm 1 chiếc graph grafana đơn giản dễ dàng với những metric:

Concurrent Session (PEAK, SESSION, LIMIT) by (device type)Concurrent User (PEAK, SESSION, LIMIT) by (device type)User TOA (time on app) by (device type)

thì mình đã thành công xuất sắc trong việc implement bài toán đo CCU theo thời gian thực trên toàn hệ thống nhưng không làm tác động quá những tới hệ thống đang chạy. Buộc phải không?

Kết luận

Đến đây, bản thân xin khép lại bài viết hết sức dài và căng thẳng kể về một ngày chủ nhật hứng chí của mình. Siêu cảm ơn chúng ta đã kiên trì theo chân bản thân tới đây. Tuy vậy mình luôn bảo các bạn đừng làm theo mình tuy thế nếu ai đó ý muốn thử sức thì hãy cứ demo nhé. Chính vì mọi thiết bị mình học tập được trê tuyến phố đi đều hữu ích và có không ít ứng dụng trong số những project không giống của mình.

Qua bài viết này mình đúc kết 3 điều (nhắc lại):

Reinvent the wheel rước lại cho chính mình nhiều thứ cơ mà chỉ khi chúng ta thực sự đọc được mình đang làm gì.Khi gặp gỡ vấn đề quá khó giải quyết, hãy ma-ke-no (mặc kệ nó) và đi làm việc thứ khác. Rồi tự nhiên và thoải mái đáp án vẫn va trực tiếp vào mặt chúng ta trước khi bạn kịp trở tay.Công nghệ - 1 đợt tiếp nhữa - không hỗ trợ ứng dụng của người tiêu dùng chạy nhanh hơn. Bạn mới là tín đồ làm điều đó.

Xem thêm: Hướng Dẫn Sử Dụng Máy Giặt Panasonic Na V90Fx1, Hướng Dẫn Cách Sử Dụng Máy Giặt Panasonic

Hết rồi.