- Tính toán những thông số đầu vào cho Bloom Filter dựa trên dữ liệu đầu vào, như chiều dài mảng dữ liệu, số hàm băm để đảm bảo hiệu suất hệ thống - Xây dựng cơ chế và và đề xuất kiến tr
Giới thiệu đề tài
Hiện nay, các công ty tài chính công nghệ (Fintech) hoạt động trong lĩnh vực cho vay trực tuyến đã ra đời và hoạt và đáp ứng nhu cầu vay vốn của người dân sau dịch COVID đặt biệt là nhóm khách hàng công nhân, tiểu thương, nhóm khách yếu thế khó tiếp cận với nguồn vốn chính thống Ngân hàng Nhà nước cho biết theo số liệu của năm 2020 thì trong khi 70% người trưởng thành ở Việt Nam có tài khoản ngân hàng, nhưng gần một nửa trong số đó không có khả năng tiếp cận tín dụng Năm 2023 cũng là một năm kinh tế đặc biệt khó khăn không những ở Việt Nam và cũng như trên toàn thế giới Với một mức lãi suất hợp lý, hợp đồng rõ ràng, kế hoạch trả nợ được thông báo ngay khi khách hàng hoàn thành xong đơn vay, tốc độ thẩm định và giải ngân nhanh do áp dụng công nghệ, các công ty tài chính này đã giúp người dân tránh được tín dụng đen và đáp ứng được nhu cầu cấp bách của người vay
Hình 1.1: Các ứng dụng cho vay trực tuyến trên ví điện tử MoMo Để duyệt đơn vay của khách hàng, thẩm định tín dụng cá nhân là nghiệp vụ quan trọng của bất kỳ ngân hàng, công ty tài chính cho vay nào nhằm đảm bảo khách hàng tốt, có khả năng trả nợ và không làm tăng dư nợ xấu cho tổ chức Để thẩm định khách hàng, các ngân hàng và tổ chức tín dụng được cấp phép của ngân hàng nhà nước sẽ truy cập vào dữ liệu của TRUNG TÂM THÔNG TIN TÍN DỤNG QUỐC GIA VIỆT NAM (CIC) để xem điểm đánh giá điểm tín dụng, số dư nợ của khách hàng đang muốn vay Tuy nhiên, một số công ty tín dụng trong lĩnh vực cho
3 vay trên mạng không hoạt động theo giấy phép của Ngân hàng Nhà nước nên chưa thể truy xuất trực tiếp vào cơ sở dữ liệu của CIC Điều này gây ảnh hưởng lớn tới vận hành của doanh nghiệp, tăng thời gian phê duyệt và giải ngân cho khách hàng
Và việc thiếu thông tin hơn dẫn đến có thể dẫn tới những quyết định như giải ngân cho khách hàng xấu, ảnh hưởng tới hoạt động của doanh nghiệp Hơn nữa, hiện nay dù suy thoái kinh tế, nhu cầu vay của người dân vẫn rất cao Tuy nhiên, các công ty tài chính tiêu dùng lại phải thu hẹp danh mục cho vay tiêu dùng do sự nở rộ của các hội/nhóm rủ nhau “bùng nợ” dẫn đến nợ xấu tăng cao Do đó danh sách đen đóng một vai trò trong việc thẩm định
Với nhu cầu có thực của các thách thức nêu trên cùng với sự đam mê dành cho việc nghiên cứu các vấn đề thuộc mảng xử lý phân tán và dữ liệu lớn, tác giả quyết định thực hiện công trình nghiên cứu "Chia sẻ danh sách đen trong lĩnh vực cho vay trực tuyến" Cụ thể hơn, hệ thống này sẽ giải quyết các bài toán về chia sẻ dữ liệu danh sách đen và bảo mật thông tin giữa các công ty tài chính trong lĩnh vực vay trực tuyến tại Việt Nam tuy nhiên vẫn không lộ thông tin khách hàng với chính những công ty đối tác chia sẻ Về mặt ứng dụng, theo tìm hiểu của của tác giả thì chưa có cơ chế chia sẻ với mục tiêu tương tự được phát triển và công bố nên hứa hẹn đây sẽ là thành phần mới góp mặt thực tiễn vào hoạt động của các công ty tài chính công nghệ
Hình 1.2: Các ứng dụng cho vay trực tuyến trên ứng dụng My MobiFone
Danh sách đen là danh sách những khách hàng, không trả nợ đúng hẹn hoặc do có điểm đánh giá thấp bởi hệ thống ra quyết định (Decision making system) Khách hàng sẽ được thêm vào bởi bằng số điện thoại, số chứng minh nhân dân (CMND), số căn cước công dân (CCCD), hoặc số tài khoản ngân hàng Tuỳ vào độ rủi ro mà khách hàng sẽ nằm trong danh sách đen một thời hạn ngắn hay dài xác định trước Do đó danh sách đen sẽ biến động theo thời gian Xây dựng một hệ thống chia sẻ danh sách đen nội bộ của mỗi công ty nhằm hạn chế bớt những khách hàng không tốt, tránh gây thất thoát tài sản của các công ty và giảm tải công việc cho các nhân viên vận hành cũng là mục tiêu của luận văn này.
Mô tả bài toán
Bài toán “Chia sẻ danh sách đen trong lĩnh vực cho vay trực tuyến” là bài toán xây dựng cơ chế chia sẻ dữ liệu và kiến trúc giữa những công ty tài chính công nghệ là đối tác của nhau mà không làm lộ thông tin của khách hàng dù là cho chính đối tác đó bằng cách sử dụng ý tưởng của cấu trúc dữ liệu Bloom Filter Trong đó, hệ thống ở mỗi tổ chức trong mạng lưới chia sẻ gửi dữ liệu danh sách các khách hàng đã được mã hoá theo cùng với nhãn thời gian (timestamp) tới một đối tác khác Hệ thống phải đảm bảo dữ liệu được gửi đi một cách an toàn và nhanh chóng, đề phòng trường hợp một đối tượng hay tổ chức tội phạm khác khi có được dữ liệu trên cũng không thể sử dụng được Việc kiểm tra xem số điện thoại người vay có nằm trong danh sách đen phải đảm bảo một hiệu suất tốt và đáng tin cậy Sự tin cậy ở đây là trả lời được câu hỏi khách hàng với số điện thoại xác định có nằm trong danh sách đen với 1 tỷ lệ sai sót mức chấp nhận được Những thách thức cần mà bài toán cần giải quyết:
- Định dạng của từng phần tử trong danh sách đen khi chia sẻ: Mỗi công ty tài chính sẽ số điện thoại theo một định dạng khác nhau
- Xây dựng cấu trúc dữ liệu danh sách đen dựa trên BloomFilter nhằm tối ưu hàm băm, giảm dương tính giả do khối lượng dữ liệu lớn Tuy nhiên, Bloom Filter chỉ cho phép thêm chứ không xóa, gây khó khăn trong quá trình quản lý danh sách đen.
- Bài toán chia sẻ dữ liệu danh sách đen giữa các tổ chức tín dụng.
Mục tiêu và nhiệm vụ của luận văn
Mục tiêu của luận văn hướng đến việc nghiên cứu và xây dựng kiến trúc hệ thống cho việc chia sẻ dữ liệu danh sách đen sử dụng các nền toán cấu trúc dữ liệu Bloom Filter Cụ thể là:
- Hiểu và sử dụng được các cấu trúc dữ liệu Bloom Filter và các biến thể cải tiếng của nó
- Nắm bắt phương pháp ghi nhận sự kiện trong hệ thống phân tán bằng 2 thuật toán Lamport clock và Vector clock
- Đề xuất kiến trúc của hệ thống
- Cuối cùng, học viên sẽ hiểu rõ hơn những vấn đề, thách thức khi áp dụng trong môi trường phân tán để giải quyết một bài toán thực tế bài toán thực tế Đánh giá tính khả thi của các phương pháp trong thực tiễn, đồng thời sẽ có góc nhìn chính xác hơn về tính toán hiệu suất cao trong môi trường phân tán nói chung
Từ mô tả bài toán, tác giả sẽ lần lượt giải quyết các vấn đề sau để đưa ra một giải pháp thiết kế và hiện thực một kiến trúc hệ thống giải quyết được bài toán của đề tài:
- Tìm hiểu nghiên cứu cấu trúc dữ liệu Bloom Filter và các biến thể cải tiến của nó là Counting Bloom Filter và Mergeable Counting Bloom
Tính toán các tham số đầu vào cho Bloom Filter:* Độ dài mảng bit: m = -n * ln(p) / (ln(2))^2* Số hàm băm tối ưu: k = m / n * ln(2)* Tỷ lệ dương tính giả: p = (1 - e^(-k*n/m))^k
- Thiết kế khảo sát, quyết định số lượng hàm băm cho Bloom Filter để đảm bảo hiệu suất việc truy xuất hiệu quả
- Nghiên cứu Lamport clock và Vector clock
- Xây dựng cơ chế để chia sẻ giữa giữa hai công ty tài chính đối tác
- Hiện thực và đánh giá tính đúng đắn hệ thống
- Kết luận các vấn đề đã giải quyết, nêu ra các vấn đề còn tồn đọng, đồng thời đưa ra các dự định cải tiến trong tương lai
Giới hạn đề tài
Vì thời gian giới hạn, vì vậy nội dung luận văn sẽ được giới hạn như sau:
- Tập chung xây dựng dữ liệu danh sách đen cho số điện thoại
- Kiến trúc của hệ thống với mô hình tập chung
- Khả năng chịu lỗi của hệ thống.
Đóng góp của luận văn
Trong luận văn, tác giả giải quyết bài toán thực tiễn và bức thiết trong lĩnh vực tài chính tiêu dùng Đóng góp của luận văn bao gồm:
- Kiến trúc và cơ chế chia sẻ dữ liệu
- Ứng dụng hiệu quả các công trình nghiên cứu
- Áp dụng công nghệ mới nhất đang được sử dụng rộng rãi, để hiện thực hệ thống.
Cấu trúc dữ liệu Bloom Filter
Cấu Trúc Dữ Liệu Bloom Filter là một cấu trúc dữ liệu đã nén để trả lời nhanh cho câu hỏi, phần tử này có nằm trong tập hợp không? Kết quả là có thể là “có” hoặc có thể hoặc không Tức là BloomFilter có thể dương tính giả (false positive) nhưng không thể có trường hợp âm tính giả (false negative) Bloom Filter bao gồm một mảng bit B có chiều dài m Khi khởi tạo, giá trị của mỗi bit trong mảng là 0 Khi mã hoá thông tin thành viên e, e sẽ được sẽ được mã hoá bởi k hàm băm độc lập nhau: Vùng giá trị trả về của hàm băm sẽ là chính là chỉ mục được dùng trong mảng bit B , sẽ được bật thành 1
Và những bit đó sẽ được gọi là bit thành viên (membership bit)
Hình 2.1: Mã hoá các phần tử a, b,c vào Bloom Filter với số hàm băm bằng 3
Dương Tính Giả (False Positive) và Số Hàm Băm Tối Ưu K (Optimal K)
Cho m là chiều dài của mảng bit n là tổng số phần tử trong tập hợp và k là tổng số hàm băm Vậy Xác suất của 1 bit vẫn bằng 0 sau khi đã thêm vào n phần tử là:
Vậy xác suất bit đó là 1 là:
Vậy một đối tượng bất kỳ, và chưa được mã hóa trong Bloom Filter , thì xác suất mà tất cả bit ở chỉ mục trả của hàm băm H của đối tượng trả về được bật là:
Trong đó là hằng số tự nhiên Euler
Rõ ràng, tỷ lệ dương tính giả sẽ giảm khi độ dài của mảng m tăng, và giảm khi số lượng phần tử n được thêm vào Bloom Filter tăng Để tìm ra số hàm băm tối ưu, ta có thể lấy đạo hàm công thức 2.3 theo k, cho vế bên trái bằng 0 và giải phương trình
Khi số hàm k* được sử dụng, ta thay vào hàm tính dương tính giả công thức2.3 sẽ là fB*:
- là số lượng hàm băm
- là số lượng hàm băm tối ưu
- là chiều dài của mảng bit
- là tổng số phần tử đã được mã hóa trong Bloom Filter
- là hằng số tự nhiên Euler
- là tỷ lệ dương tính giả
- là tỷ lệ dương tính giả khi số hàm băm tối ưu được sử dụng.
Counting Bloom Filter
Việc loại bỏ một phần tử trong Bloom Filter là không thể Bởi vì mỗi bit bằng 1 sẽ được sử dụng chung bởi các phần tử khác nhau Ta không thể đơn giản gán bit thành 0 được vì nó dẫn tới việc lược bỏ một phần tử khác Counting Bloom Filter dùng một mảng của bộ đếm (counter) C với chiều dài l Mỗi bộ đếm trong mảng đều được khởi tạo là 0 Cũng giống như Bloom Filter truyền thống, chúng ta mã hoá một phần tử e bằng k hàm băm Mỗi hàm băm sẽ trả về giá trị từ 0 tới l - 1 là chỉ mục của trong mảng bộ đếm C Chúng ta sẽ tăng giá trị của bộ đếm tại vị trí của số đếm lên 1
Hình 2.2: Mã hoá các phần tử a, b,c vào Counting Bloom Filter với số hàm băm bằng
3 Khi muốn xoá một phần tử e khỏi tập hợp, chúng ta cũng băm phần tử đó và có tập giá trị các chỉ mục ta sẽ giảm giá trị tại các vị trí số đếm xuống 1
Khi kiểm tra một phần tử bất kỳ e’ có nằm trong Counting Bloom Filter không, ta cũng băm đối tượng thành bằng k hàm băm Sau đó
13 kiểm tra giá trị tại các vị trí do hàm băm trả về trong mảng C có khác 0 hay không? Nếu tất cả đều khác 0, thì có thể kết luận đối tượng đó nằm trong tập hợp.
Dương Tính Giả (False Positive), Số Hàm Băm Tối Ưu (Optimal K), Kích Thước Của Bộ Đếm (Counter Size) và Độ Đếm Tràn (Counter Overflow) của
Băm Tối Ưu (Optimal K), Kích Thước Của Bộ Đếm (Counter Size) và Độ Đếm Tràn (Counter Overflow) của Counting Bloom Filter
Cho là chiều dài của mảng bộ đếm, là tổng số phần tử đã được mã hả trong Counting Bloom Filter tập hợp và là số hàm băm Cùng phương pháp phân tích như phần 2.2, ta có xác xuất 1 phần tử trong mảng số là 0 sau khi đã thêm n phần tử là:
Vậy xác suất phần tử đó đó khác 0 là:
Vậy với một đối tượng bất kỳ, và không nằm trong Counting Bloom Filter, thì xác suất mà tất cả các số ở chỉ mục được hàm băm trả về lớn hơn 0 là:
Trong phương trình 3.3, e là hằng số Euler, là một số vô tỷ quan trọng trong toán học Từ hàm số này, chúng ta có thể tính toán số lượng hàm băm tối ưu k* bằng cách lấy đạo hàm của phương trình 3.3, tương tự như phương pháp đã được trình bày trong chương 2.2.
Trong đó là logarit cơ số tự nhiên Euler Khi số hàm k* được sử dụng, ta thay vào hàm tính dương tính giả sẽ là fC*:
- là số lượng hàm băm
- là số lượng hàm băm tối ưu
- là chiều dài của mảng bộ đếm
- là tổng số phần tử đã được mã hóa trong Bloom Filter
- là hằng số tự nhiên Euler
- là tỷ lệ dương tính giả
- là tỷ lệ dương tính giả khi số hàm băm tối ưu được sử dụng
Như vậy, Counting Bloom Filter có cùng tỷ lệ dương tính giả với Bloom Filter truyền thống
Bộ Đếm trong Counting Bloom Filter là được chỉ định trước và có giới hạn Tất cả đều có cùng độ dài cố định Giả sử, mỗi bộ đếm có t bit Giá trị của bộ đếm là từ khoảng tới Nếu giá trị bộ đếm đang là và ta mã hoá một phần tử mới, bộ đếm sẽ tăng lên 1, tràn bộ đếm (counter overflow) sẽ xảy ra Nếu giá trị càng nhỏ, thì việc tràn bộ đếm sẽ xảy ra thường xuyên hơn Tuy nhiên nếu giá trị lớn sẽ tốn bộ nhớ Cho là một biến ngẫu nhiên là giá trị của bộ đếm sau n lần thêm phần tử vào BloomFilter, sẽ tuân theo phân phối xác suất Binomial:
15 Ở đây, được xác định bởi công thức:
Xác suất để bộ đếm lớn hơn hoặc bằng giá trị y là:
Trong đó: là giai thừa giảm dần :
Rõ ràng, Ta có thể giới hạn bằng:
Xác suất bất kỳ bộ đếm c nào mà lớn hơn hoặc bằng y sẽ là:
Và khi số hàm băm tối ưu k* (công thức 2.11) được áp dụng thì ta có:
(2.19) Ý nghĩa các ký hiệu trong phần 2.4 :
- là xác suất để điều kiện đó xảy ra
- là chiều dài của mảng bộ đếm
- là giai thừa của biến x
- là hằng số tự nhiên Euler
- là logarit cơ số tự nhiên e
- là tổng số phần tử có trong Bloom Filter
Trong thực tế, nếu tràn bộ đệm xảy ra, ta vẫn có thể giữ giá trị của bộ đếm Nhưng qua quá nhiều phân tử, có thể dẫn tới tình huống tỷ lệ dương tính giả cao.
Mergeable Counting Bloom Filter
Thêm một phần tử
Để thêm một phần tử vào mergeCBF, ta không chỉ băm phần tử đó bằng k hàm băm mà còn phải sắp xếp các và chọn mảng bit nào để chứa các giá trị trả về của hàm băm Để đảm bảo việc xếp các bit vào mảng bit một cách ít đụng độ và hiệu quả, nhóm tác giả dùng giới thiệu một thuật toán lấy ý tưởng từ thuật toán Cuckoo Hash tên là thuật toán sắp xếp virtual-Cuckoo Ý tưởng của thuật toán Cuckoo hash là tìm ra vị trí của phần tử trong mảng, nếu vị trí ô trong mảng đã có một phần tử chiếm dụng, chúng ta sẽ đẩy phần tử đã có ra khỏi ô đó, chèn phần tử mới vào ô hiện tại, tìm một vị trí mới cho phần tử cũ Quá trình này tiếp diễn cho tới khi không còn đụng độ nửa Cuckoo Hash đảm bảo việc sử dụng bộ nhớ một cách hiệu quả vì nó khuyến khích nhiều ô trong mảng được sử dụng hơn
Trong mergeCBF, chúng ta ghi nhận một phần tử với “1” k bit trong k ô Với virtual-Cuckoo, nếu chỉ mục của hàm băm trả về đã là là trong mảng bit đã được bật là “1”, chúng ta không cần đẩy giá trị bit “1” ra khỏi ô đó và chèn bit “1” vào ô khác Chúng ta sẽ bỏ qua ô đã bị chiếm dụng và tìm một khác cho phần tử mới Kết quả thuật toán vẫn tuân thủ theo quý ước của Cuckoo Hash Thuật toán virtual- Cuckoo được mô tả dưới đây
18 i ; là chỉ mục của ô để chứa phần tử mới
; là nhóm của những g ô ứng viên
; là chỉ mục mới được chọn từ ô ứng viên ở trên 1: if ô thứ i của mảng được bật then
Thuật toán thêm một phần tử vào mergeCBF được mô tả như sau:
- Băm một phần tử với k hàm băm Giá trị trả về tương ứng là kết trả về của hàm băm cũng là chỉ mục trong mảng bit
- Với mỗi , ta dùng thuật toán sắp xếp virtual-Cuckoo để tìm mảng bit mà giá trị tại , ta bật
- Lặp lại quá trình trên k lần cho k hàm băm tới khi tất cả bit trả về từ hàm băm được bật.
Truy vấn một phần tử
Để truy vấn một phần tử, ta chỉ cần băm phần tử đó bằng k hàm băm và kiểm tra các ô ở chỉ mục của hàm băm trả về ở mảng orBarr Nếu tất cả các chỉ mục đều được bật, thì phần tử có thể nằm trong mergeCBF Còn ngược lại, nếu một trong các ô chưa được bật, thì phần tử đó chắc chắn không nằm trong mergeCBF
Xóa phần tử
Để xóa một phần tử, cơ chế cũng giống như là thêm phần tử Chúng ta sử dụng thuật toán virtual-Cuckoo để tìm ra ô cuối cùng và tắt bit đó thành 0 Thuật toán mô tả như sau:
- Nếu phần tử đó tồn tại trong mergeCBF, tìm k ô trả về bởi thuật toán virtual-Cuckoo và tắt bit ở ô đó thành 0
Hợp mergeCBF
Để hợp hai mergeCBF, ta cần ước lượng tổng số phần tử đã được thêm vào mergeCBF Theo lý thuyết bi và thùng (balls and bins) [23], một ô bit được đặt là 1 với xác suất theo phân phối Poisson Do đó, giả sử ô có giá trị bit 1, là số lần một ô được đặt thành 1, giá trị ước tính của số phần tử được được chèn vào mergeCBF là sẽ được suy ra từ công thức sau:
Trong đó là hằng số Euler Để chọn ô từ ô, chúng ta có sự kết hợp của
Quá trình hợp hai mergeCBF gồm những bước sau:
- Ước lượng tổng số lượng phần tử trong hai mergeCBF để không vượt quá sức chứa của mergeCBF Nếu vượt qua thì ta dừng lại quá trình và báo cáo lại lỗi
- Với mọi , ta thực hiện phép or bit của mảng bit thứ j của mergeCBF thứ nhất và mảng bit j của mergeCBF thứ 2
Hàm băm
MurmurHash
MurmurHash được tạo ra bởi Austin Appleby vào năm 2008 MurmurHash là một thuật toán băm phi tuyến tính, có khả năng tạo ra giá trị băm ngẫu nhiên từ dữ liệu đầu vào Nó sử dụng một sự kết hợp của các phép dịch bit, phép XOR và phép nhân để tạo ra giá trị băm
Một trong những ưu điểm nổi bật của MurmurHash là tốc độ xử lý nhanh và khả năng phân tán dữ liệu hiệu quả Thuật toán này tận dụng cơ chế băm tương tự như việc trộn và xoá bit, tạo ra giá trị băm với độ phân tán cao và ít đụng độ
MurmurHash có thể được sử dụng cho nhiều loại dữ liệu khác nhau, bao gồm chuỗi ký tự, số nguyên, dữ liệu nhị phân và hơn nữa
MurmurHash sở hữu tính trộn tuyệt vời (hiệu ứng avalanche), theo đó thay đổi nhỏ trong đầu vào sẽ dẫn tới thay đổi lớn trong giá trị băm đầu ra Đặc tính này giúp tránh va chạm và tăng tính ngẫu nhiên của giá trị băm Tuy nhiên, lưu ý rằng MurmurHash không phải là hàm băm dùng cho mục đích bảo mật.
MurmurHash có ba phiên bản:
- MurmurHash 1 là một hàm băm 32-bit
- MurmurHash 2 là phiên bản cải tiến của MurmurHash 1, được thiết kế để khắc phục một số hạn chế và lỗ hổng Nó hoạt động trên nền tảng 32-bit hoặc 64-bit và tạo ra giá trị băm 32-bit
- MurmurHash 3 là phiên bản mới nhất của họ MurmurHash và cung cấp nhiều cải tiến Nó hỗ trợ giá trị băm 32 bit và một 128 bit và đồng thời chống lại sự tấn công hàm băm
Thuật toán MurmurHash cho giá trị băm 32 bit được trình bày dưới dạng mã giả dưới đây:
Input: data ; data dược hash seed; giá trị khởi tạo
; giá trị băm trả về
8: for each fourByteChunk of data do 9: k ← fourByteChunk
16: with any remainingBytesInKey do 17:remaining_bytes ← length mod by 4;
18: if remaining_bytes > 0 then 19: last_chunk ← last remaining_bytes of data
20: last_chunk ← last_chunk ROL (8 × remaining_bytes);
22: last_chunk ← last_chunk ROL r1;
23: hash ← hash XOR last_chunk;
24: end if 25: hash ← hash XOR length;
27: hash ← hash ×0x85ebca6b ; 28: hash ← hash XOR (hash >> 13);
FNV
FNV (Fowler-Noll-Vo) là một thuật toán băm đơn giản và hiệu quả được sử dụng trong nhiều ứng dụng Thuật toán này được đặt tên theo tên ba tác giả: Glenn Fowler, Landon Curt Noll và Phong Vo Hai phiên bản phổ biến của FNV là FNV-1 và FNV-1a
Thuật toán FNV-1 được mô tả dưới đây:
Input: data ;data dược hash FNV_prime;giá trị FNV_prime trong bảng trên offset_basic;Giá trị offset_basic trong bảng trên
Output: hash; giá trị băm trả về
1: hash = offset_basic 2: for byte in data do 3: hash ← hash × FNV_prime
Thuật toán FNV-1a được mô tả dưới đây:
Input: data ; data dược hash FNV_prime; giá trị FNV_prime trong bảng trên offset_basic; Giá trị offset_basic trong bảng trên
Output: hash; giá trị băm trả về
1: hash ← offset_basic 2: for byte in data do 3: hash ← hash XOR byte
Sự khác biệt duy nhất giữa FNV-1a và FNV-1 là thứ tự của phép toán nhân và phép toán XOR Trong đó các giá trị của FNV_prime và offset_basic là các giá trị phụ thuộc vào chiều dài của giá trị băm được trả về được định nghĩa ở bảng sau:
Bảng 2.1 Bảng giá trị của FNV_prime và offset_basic
Lamport clock
Để Lamport clock là một cơ chế để xác định thứ tự của cá sự kiện trong một hệ thống phân tán khi không có một đồng hồ chung (global clock) hay một thời gian tham chiếu tập trung (centralized time reference) Ý tưởng của Lamport clock là mỗi sự kiện trong hệ thống đều được gán cho một đồng hồ logical (logical clock) để cho phép xác định thứ tự của sự kiện Do đó chúng ta có thể xác định được quan hệ nhân quả dù không có một đồng hồ chung Thuật toán Lamport được mô tả như sau:
- Mỗi tiến trình, nút trong hệ thống phân tán sẽ duy trì một đồng hồ logical riêng với giá trị khởi tạo
- Mỗi sự kiện xảy ra ở từng tiến trình hay nút, đồng hồ logic riêng của tiến trình đó được tăng lên một
- Khi tiến trình gửi một thông điệp (message) tới một tiến trình khác, ở tiến trình gửi đồng hồ logical của mình lên một, đồng thời hệ thống cũng gửi đồng hồ logical của nó tới tiến trình còn lại
- Ở tiến trình nhận, đồng hồ logic của tiến trình nhận sẽ bằng số lớn nhất của đồng hồ logic của tiến trình gửi và tiến trình nhận, và tăng thêm 1
- Thứ tự của các sự kiện sẽ dựa trên trên đồng hồ logic của mỗi sự kiện:
+ Nếu sự kiện A xảy ra trước sự kiện B, nghĩa là đồng hồ logic của A sẽ nhỏ hơn đồng hồ logical của B,
+ Tuy nhiên, điều ngược lại không đúng, nếu , không có nghĩa là A xảy ra trước B
+ Nếu sự kiện có cùng đồng hồ thời gian , cũng không nghĩa là A và B xảy ra cùng một lúc Có thể hai sự kiện A và B xảy ra đồng thời
Lamport clock được sử dụng nhiều trong các cơ sở dữ liệu phân tán (distributed database), và cái hệ thống gửi thông điệp (message passing) hay trong kiến trúc hướng sự kiện (Event driven architecture) Nó cung cấp sự đồng bộ hoá và một thứ tự sự kiện xảy ra trong hệ thống phân tán Tuy nhiên nó không xem xét tới thời gian của đồng hồ vật lý
Hình 2.3: Lamport clock cho hệ thống có ba tiến trình
Trong ví dụ trên hình 2.3, chúng ta có 3 tiến trình A, B, C trong hệ thống phân tán Như hình, chúng ta có những sự kiện xảy ra trong hệ thống:
- A gửi thông điệp mA tới B
- A xảy ra một sự kiện, B gửi thông điệp mB tới C
Vector clock
Vecto clock timestamp là một khái niệm trong hệ thống phân tán, là sự mở rộng của Lamport Clocks, giúp theo dõi và sắp xếp thứ tự các sự kiện xảy ra trên nhiều tiến trình.
Việc sử dụng thời điểm đồng hồ vector cho phép các quy trình so sánh và xác định thứ tự của các sự kiện Bằng cách so sánh các giá trị trong các vector clock, ta có thể biết rõ xem sự kiện A đã xảy ra trước hay sau sự kiện B, hoặc liệu chúng đồng thời hay không
Thuật toán Vector clock bao gồm các bước sau:
- Mỗi tiến trình hay nút, ta khởi tạo một vector có độ dài bằng tổng số dài tiến trình, nút trong hệ thống phân tán
- Mỗi sự kiện xảy ra ở tiến trình i, ta tăng giá trị tại chỉ mục i trong vector lên 1,
- Nếu tiến trình i gửi một thông điệp tới tiến trình j, tại tiến trình i, ta tăng giá trị vector tại i lên 1: Đồng thời gửi vector sang tiến trình j
+ Giá trị của mỗi điểm của vector sẽ là giá trị là lớn nhất của 2 vector va : + Vector tại j sẽ được tăng lên 1
Nguyên tắc so sánh hai vector clock để xác định thứ tự các sự kiện xảy ra trong hệ thống:
- Nếu giá trị của một phần tử trong vector ứng với sự kiện A nhỏ hơn phần tử tương ứng trong vector ứng với sự kiện B, thì sự kiện A đã xảy ra trước sự kiện B
- Nếu giá trị của một phần tử trong vector ứng với sự kiện A lớn hơn phần tử tương ứng trong vector ứng với sự kiện B, thì sự kiện B đã xảy ra trước sự kiện A
Nếu mọi giá trị trong vector của sự kiện A bằng giá trị tương ứng của vector sự kiện B, thì sự kiện A xảy ra đồng thời hoặc không xác định so với sự kiện B.
Hình 2.4 : Vector clock có ba tiến trình Trong ví dụ trên hình 2.2, chúng ta có 3 tiến trình trong hệ thống phân tán Mỗi tiến trình sẽ lưu trữ một vector có độ dài là 3, và khởi tạo giá trị là 0 Như hình, chúng ta có những sự kiện xảy ra trong hệ thống:
- P1 tạo ra một sự kiện A1.
- P2 tạo ra một sự kiện B1
- P1 gửi một sự kiện A2 tới P2
- P1 tạo ra một sự kiện A4
- P2 tạo ra một sự kiện B3
+ P3: Ở sự kiện A2 trong ví dụ trên, từ vector P2[2, 2, 0] ta có thể kết luận có 2 sự kiện xảy ra ở P1, và 2 sự kiện xảy ra ở P2
Thông qua việc sử dụng thời điểm vector clock, hệ thống phân tán có thể định rõ thứ tự của các sự kiện và giải quyết các vấn đề như đồng bộ dữ liệu và phát hiện xung đột Điều này đóng vai trò quan trọng trong việc đảm bảo tính nhất quán và hiệu năng trong các hệ thống phân tán
Chương 3 CÔNG TRÌNH NGHIÊN CỨU LIÊN QUAN
Bloom Filter
Bắt đầu từ công trình nghiên cứu về cấu trúc dữ liệu gọn nhẹ và hiệu quả của tác giả Burton Howard Bloom vào năm 1970 [1] là Bloom Filter, đã có được rất nhiều nghiên cứu để cải tiến và ứng dụng nó ra đời Một trong những công trình tổng hợp đáng chú ý là "Theory and Practice of Bloom Filters for Distributed Systems" [4] của Sasu Tarkoma, Christian Esteve Rothenberg, Eemil Lagerspetz Công trình này đã tổng hợp vào việc áp dụng Bloom Filter trong hệ thống phân tán để giảm tải công việc truy vấn dữ liệu qua mạng Bài báo đã liệt kê khoảng 20 biến thể khác của Bloom Filter và ứng dụng của chúng trong hệ thống phân tán như caching, hệ thống ngang hàng, định tuyến và chuyển tiếp (routing and forwarding) và tổng hợp dữ liệu đo đạc (measurement data summarization) Một số nghiên cứu khác cũng liên quan khác như tìm kiếm bảng định tuyến [8,9] (routing-table lookup), hệ thống ngang hàng [10, 11, 12] (peer to peer system), xử lý truy vấn cơ sở dữ liệu [13] (database query processing), bộ nhớ đệm hợp tác [14] (cooperative caching) hay thiết kế tường lửa [16] (firewall design)
Trong ứng dụng tìm kiếm bảng định tuyến, nhóm tác giả S Dharmapurikar, P
Krishnamurthy và D Taylor đã giới thiệu công trình “Longest Prefix Matching
Bộ lọc Bloom sử dụng chiều dài tiền tố trong bảng định tuyến từ 8 đến 32 Từ địa chỉ đích của gói tin, bộ định tuyến có thể trích xuất tới 25 tiền tố có độ dài khác nhau và kiểm tra sự tồn tại của tiền tố trong bảng định tuyến Một nghiên cứu liên quan là "IPv6 Lookups Using Distributed and Load Balanced Bloom Filters for 100 Gbps Core Router Line Cards" của H Song, F Hao, M Kodialam và T Lakshman Do tốc độ Internet tăng và việc sử dụng IPv6 ngày càng phổ biến, bộ định tuyến phải khớp hàng trăm nghìn tiền tố có độ dài khác nhau Các tác giả đề xuất sử dụng bộ lọc Bloom phân tán và cân bằng tải để đáp ứng nhu cầu này.
Công trình nghiên cứu "Applications of Bloom Filters in Peer-to-peer Systems: Issues and Questions" của Hailong Cai, Ping Ge và Jun Wang [10] tập trung vào việc nghiên cứu sử dụng Bloom Filter trong các hệ thống ngang hàng để chia sẻ dữ liệu hiệu quả Công trình cũng đồng thời đề cấp tới các vấn đề nghiệm trọng có thể xảy ra khi sử dụng Bloom Filter trong hệ thống P2P Trong công trình "Efficient and Scalable Query Routing for Unstructured Peer-to-Peer Networks" [11] của tác giả
A Kumar, J Xu, và E.W Zegura, đã đề xuất một giao thức truy vấn định tuyến
(query routing protocol), cho phép tiêu thụ ít băng thông bằng cách duy trì một bảng định tuyến xác suất (probabilistic routing table) ở mỗi nút (node) Bảng định tuyến này được xây dựng một Bloom Filter giảm theo hàm số mũ (Exponentially Decaying Bloom Filter) cho phép được nén ở mức độ cao và cho phép tổng hợp và truyền bá hiệu quả
“Network Firewalling with Bloom Filters” [16] của các tác giả Maccari, R Fantacci, P.Neira, and R.Gasca, đã nêu ra vấn đề về lọc gói tin trong mạng không dây đa bước (mesh multi-hop wireless) là vô cùng thách thức Vì số lượng kết nối có thể là bậc hai so với thiết bị cuối ở trong mạng Các tác giả đã giới thiệu giải pháp là một tường lửa phân tán (distributed firewall) trong mô hình mạng không dây đa bước dựa trên Bloom Filter
32 Để đáp ứng nhu cầu dữ liệu càng trở lên lớn trong môi trường Internet, công trình dữ liệu "Scalable Bloom Filters" của Almeida và các cộng sự [8] tập trung vào việc xây dựng Bloom Filter có khả năng mở rộng để đáp ứng nhu cầu xử lý dữ liệu lớn trong các hệ thống phân tán Công trình này đề xuất một phương pháp để tự động phân chia và kết hợp các Bloom Filter con thành một Bloom Filter lớn hơn Điều này cho phép hệ thống mở rộng theo quy mô và linh hoạt xử lý dữ liệu lớn mà không ảnh hưởng đến hiệu suất truy vấn.
Lamport Clock và Vector Clock
Leslie Lamport's seminal paper, "Time, Clocks, and the Ordering of Events in a Distributed System" [1], published in 1978, introduced the notion of time synchronization in distributed systems This breakthrough laid the foundation for the development of distributed protocols and algorithms that rely on accurate and consistent timekeeping across multiple nodes.
Sau đó, năm 1985, K Mani Chandy và cũng chính Leslie Lamport cùng giới thiệu công trình “Distributed Snapshots: Determining Global States of a Distributed System” [19] để xác định được trạng thái của chung của một hệ thống phân tán bằng cách qua bản lưu phân tán (distributed snapshots) của hệ thống mà không ảnh hưởng tới tác vụ chính của hệ thống
Một công trình khởi đầu của "Vector Clocks: Relating Concurrent Events in Distributed Systems" của Colin J.Fidge [19] Nghiên cứu này đã giới thiệu khái niệm và cơ sở lý thuyết về Vector Clock, đặc biệt là trong ngữ cảnh của các hệ thống phân tán Công trình này đã tạo ra một khung việc để xác định và so sánh sự xảy ra đồng thời của các sự kiện trong hệ thống phân tán, mở ra cánh cửa cho việc xây dựng các thuật toán đồng bộ và phân tán trong các môi trường phức tạp
Chương 4 PHƯƠNG PHÁP GIẢI QUYẾT VẤN ĐỀ
Xây dựng dữ liệu danh sách đen
Dữ liệu danh sách đen là dữ liệu từ hoạt động của các công ty tài chính, có dung lượng lớn, tốn kém khi lưu trữ và chia sẻ trên Internet Để giải quyết vấn đề này, việc xây dựng dữ liệu danh sách đen dùng Bloom Filter là hợp lý vì nó cho phép chia sẻ nhanh dữ liệu có dung lượng nhỏ, giảm độ trễ, tăng hiệu suất truy vấn, có tỷ lệ sai sót thấp và đảm bảo bảo mật dữ liệu gốc (số điện thoại, thông tin khách hàng) Bloom Filter còn giúp tiết kiệm chi phí tính toán do tính nén và chi phí truy vấn thấp.
Tuy nhiên, Bloom Filter có một nhược điểm là không hỗ trợ xóa phần tử khỏi tập hợp Trong khi đó trong hoạt động của các công ty tài chính, việc cập nhập danh sách đen xảy ra rất thường xuyên, trong quá trình vận hành Nếu ta sử dụng Bloom Filter, hệ thống phải xây dựng lại Bloom Filter từ đầu trước khi cập nhập và gửi qua cho đối tác chỉ sẻ Việc này sẽ rất tốn thời gian và làm chậm quá trình cập nhập danh sách đen Để giải quyết vấn đề này, ta có thể xem xét một biến thể cải tiến có hỗ trợ xóa phần tử là Counting Bloom Filter (CBF) Ta có thể đạt được một tỷ lệ dương tính sai tương tự với Bloom Filter nếu cùng số phần tử được mã hóa vào tập hợp CBF sẽ làm tăng dung lượng của dữ liệu vì nó sử dụng mảng bộ đếm (counter) thay vì mảng bit giống Bloom Filter Nhưng CBF có một điểm yếu là không hỗ trợ việc hợp hai CBF có cùng chiều dài vector vì không loại bỏ được phần tử trùng lặp, nó sẽ dẫn tới khả năng làm bộ đếm tràn tăng lên
Mergeable Counting Bloom Filter (mergeCBF) đáp ứng các yêu cầu trên Nó là một phiên bản cải tiến của CBF nên nó hỗ trợ việc xóa phần tử khỏi danh sách đen Ngoài ra mergeCBF còn hỗ trợ việc hợp hai Bloom Filter có cùng độ dài mảng dữ liệu Ước tính số lượng phần tử trong danh sách đen của một công ty khoản tới phần tử Vậy nếu hệ thống khoảng 5 thành viên tham gia thì ta ước lượng tổng số danh sách đen lớn nhất là , Giả sử tỷ lệ dương tính giả (false positive) mong muốn là 0.001 (0.1%) ,
Với độ dài của mảng bit là 71 887 937, ta sẽ áp dụng công thức 2.11, thì số hàm băm tối ưu sẽ là Ước tính dung lượng, xác xuất tràn khi ta sử dụng CBF, ta dùng công thức 2.11
Bảng 4.1 Bảng ước tính dung lượng khi số bit được sử dụng
Dung lượng 34.28 MB 68.56 MB 137.12 MB 274.24 MB
Như ta thấy, với t = 4 bit tương ứng với số mảng bit là 16, xác suất bị tràn bộ đếm là rất nhỏ, nên ta chọn số lượng mảng bit là 16 là tối ưu về mặt bộ nhớ và tỷ lệ dương tính giả cho CBF.
Kiến trúc hệ thống
Để đáp ứng bài toán chia sẻ danh sách đen, tác giả đề xuất kiến trúc hệ thống như sau:
- Một server trung tâm gọi là Bloom Filter Server (BFS) BFS sẽ quản lý toàn bộ thông tin danh sách đen đã được mã hoá dưới cấu trúc dữ liệu Mergeable Counting Bloom Filter (mergeCBF) của tất cả các công ty cùng thời gian logical của hệ thống Ngoài ra BFS còn sẽ giữa cấu hình mạng lưới liên kết giữa các công ty là đối tác của nhau Các dữ liệu về danh sách đen và về thời gian logical sẽ được lưu trên bộ nhớ RAM và một cơ sở dữ liệu trên bộ nhớ
(In memory DB) Điều này đảm bảo BFS có khả năng mở rộng theo chiều ngang (scale horizontally) và kháng lỗi
Mỗi công ty thành viên sẽ sử dụng Bloom Filter Client (BFC), chịu trách nhiệm tích hợp với hệ thống vận hành sẵn có, mã hóa danh sách đen thành mergeCBF có cùng độ dài mảng bit BFC lưu trữ danh sách đen của chính mình và của các đối tác, được tổng hợp bởi Bloom Filter Server (BFS) BFC xử lý và lưu trữ dữ liệu trên cả bộ nhớ và cơ sở dữ liệu trên bộ nhớ, tương tự như BFS.
Message Broker đóng vai trò cầu nối giữa BFS và BFC, cho phép trao đổi thông tin bất đồng bộ và giảm sự phụ thuộc giữa chúng Message Broker sử dụng hàng đợi (queue) để đảm bảo BFS và BFC có thể nhận được dữ liệu được gửi từ phía bên kia.
Hình 4.1: Kiến trúc hệ thống
Luồng chạy của hệ thống được mô tả dưới đây:
- BFC sẽ đọc dữ liệu từ hệ cơ sở dữ liệu và xây dựng dữ liệu danh sách đen được mã hóa dưới dạng mergeCBF
- BFC sẽ gửi một thông điệp tới BFS qua hàng đợi của BFS ở Message
Broker, thông điệp này bao gồm: danh sách đen đã được mã hóa và thời gian logical hiện tại
BFS lắng nghe hàng đợi và lấy thông báo về Ở BFS, chúng ta có hai cơ chế xử lý thông báo: chế độ đồng bộ và bất đồng bộ.
+ Cơ chế đồng bộ: BFS sẽ quét hết dữ liệu mới nhất của những công ty đối tác với công ty hiện tại Nếu dữ liệu các công ty đối tác đã sẵn ở thời gian logical mới nhất, thì BFS sẽ gửi lại một thông điệp bao gồm thời gian logical và danh sách đen tổng hợp công ty đối tác của công ty gửi thông điệp vào hàng đợi của BFC BFC sẽ lắng nghe hàng đợi này và cập nhập danh sách đen tổng hợp của nó
+ Cơ chế bất đồng bộ, BFS sẽ có cùng hành vi giống chế độ đồng bộ nếu dữ liệu của các công ty thành viên đã sẵn sàng Trong trường hợp một trong công ty đối tác không gửi dữ liệu, BFS sẽ có một tiến trình định kỳ để quét công ty chưa gửi danh sách đen Sau đó BFS sẽ tổng hợp danh sách đen tổng hợp từ dữ liệu mới nhất của công ty chưa gửi Sau đó BFS sẽ gửi lại danh sách đen vào hàng đợi cho BFC đảm bảo hệ thống vận hành trơn chu Ngoài ra BFS cũng cần cấu hình một biến epsilon, là khoảng cách lớn nhất giữa hai thời gian logic mà BFS còn áp dụng chính sách trên
Trong ví dụ hình 4.2, ta có 3 công ty A, B và N theo cơ chế đồng bộ Tại thời điểm đồng bộ dữ liệu là 0, 1, 2, thời gian logical của A, B, N đều giống nhau
Trong ví dụ hình 4.3, ta cũng có 3 công ty A, B, N theo cơ chế bất đồng bộ Tại thơi điểm t = 0, thì hệ thống đồng bộ dữ liệu như bình thường Thời điểm t = 1, công ty B không gửi dữ liệu danh sách đen Lúc này hệ thống vẫn tiến hành đồng bộ dữ liệu bình thường vì còn nằm trong giới hạn epsilon cho phép Hệ thống sẽ lấy dữ liệu danh sách đen cập nhập gần nhất của B để tổng hợp và gửi cho A và N
38 Hình 4.2 : Chế độ đồng bộ với 3 công ty A, B, N
Hình 4.3: Chế độ bất đồng bộ với 3 công ty A, B, N Trong đó công ty B không gửi danh sách đen cập nhập
Các công ty sẽ cập nhập danh sách đen theo thời gian cố định Khi BFC gửi dữ liệu cập nhập về BSF, BFS sẽ đợi cho tới khi các công ty là đối tác của công ty thành viên của đó gửi về danh sách đen tại thời điểm t và đồng thời nó sẽ lưu giữ
40 một bản danh sách đen theo thời gian logical t của các công ty thành viên Khi các công ty đối tác đã cập nhập danh sách đen xong, BFS sẽ tổng hợp các danh sách đen của công ty đối tác tại thời điểm t đó và gửi lại BFC.
Hiện thực hệ thống
Ngôn ngữ lập trình và nền tảng (framework)
Tác giả sẽ dụng ngôn ngữ Java để hiện thực cho hệ thống này Java là một ngôn ngữ mạnh mẽ để xây dựng hệ thống cho doanh nghiệp nhờ những ưu điểm sau:
- Nền tảng độc lập: hệ thống có thể chạy trên bất cứ hệ điều hành, nền tảng nào, chỉ cần máy tính đó đã cài máy ảo Java (Java Virtual Machine)
- Hệ sinh thái vững mạnh Ngôn ngữ Java đã ra đời đời từ 1995 và có vô số những thư viện, framework để đơn giản hóa quá trình phát triển
- Khả năng mở rộng: Ứng dụng Java có dễ dàng mở rộng theo chiều ngang (scale horizontally) bằng cách chạy nhiều bản thế của ứng dụng trên nhiều máy khác nhau
- Cộng đồng và hỗ trợ: Java có một cộng động lớn các nhà phát triển lớn Nghĩa là chúng ta có thể truy cập vào các tài nguyên bao gồm các tài liệu, các diễn đàn, các thư viện bên thứ ba Ngoài ra các tổ chức cung cấp hỗ trợ thương mại cho Java
- Là một ngôn ngữ mạnh mẽ: Java là kiểu mạnh, dễ dàng kiểm soát lỗi và các ngoại lệ (Error và Exception) một cách mạnh mẽ, giảm các lỗi khi chạy chương trình, giúp tăng tính ổn định của hệ thống
Nền tảng Spring Boot được lựa chọn để hiện thực hóa hệ thống, nhằm tạo thuận lợi và tăng tốc độ phát triển hệ thống doanh nghiệp Spring Boot cung cấp các lợi ích đáng kể, bao gồm:
- Server web nhúng: hỗ trợ Tomcat, Jetty, Undertow Điều này giúp loại bỏ việc cấu hình máy chủ bên ngoài, đơn giản hóa việc triển khai và giảm chi phí bảo trì máy chủ web
Tự động cấu hình ứng dụng dựa trên các đường dẫn thư viện phụ thuộc giúp các nhà phát triển tiết kiệm thời gian và công sức đáng kể Giải pháp này loại bỏ nhu cầu viết các tệp cấu hình phức tạp, đơn giản hóa đáng kể quy trình phát triển ứng dụng.
Library management: simplifies and automates management of a related library of dependent components (jar library files) For example, the Spring boot automatically downloads all libraries related to the web for web components: spring-boot-starter-tomcat (web server), spring-web (web library), jackson-databind (json file processing library), spring-boot-starter-validation (validation check)
- Cấu hình bên ngoài: Spring Boot hỗ trợ cấu hình bên ngoài bằng cách sử dụng file properties, YAML, biến môi trường hoặc đối số dòng lệnh Điều này giúp dễ dàng định cấu hình ứng dụng cho các môi trường khác nhau mà không cần thay đổi mã nguồn Ví dụ như Bloom Filter Server giữa hai chế độ “sync” và “async” chỉ cần thay đổi cấu hình và khởi động lại ứng dụng BFS
Cho cơ sở dữ liệu trên bộ nhớ, tác giả đã cân nhắc và chọn Redis Các ưu điểm của Redis bao gồm:
- Redis được thiết kế để có hiệu suất cao với thời gian truy xuất ngắn và khả năng xử lý hàng ngàn truy vấn mỗi giây
- Redis hỗ trợ nhiều cấp độ dữ liệu như Strings, Lists, Sets, Sorted Sets, Hashes, Bitmaps, HyperLogLogs, Streams Điều này giúp người phát triển chọn cấu trúc dữ liệu phù hợp với mô hình dữ liệu của họ
- Redis có khả năng mở rộng dễ dàng bằng cách thêm các máy chủ mới hoặc sử dụng tính năng phân vùng (partitioning) để chia nhỏ dữ liệu trên nhiều máy chủ
- Các thư viện client Redis được hỗ trợ cho nhiều ngôn ngữ lập trình, bao gồm Java, Python, Ruby, Node.js, và nhiều ngôn ngữ khác
- Redis có một cộng đồng phát triển lớn, nơi có sẵn tài liệu phong phú và nhiều nguồn tài trợ từ cộng đồng.
Kết nối hệ thống
Kết nối giữa Bloom Filter Server (BFS) và Bloom Filter Client (BFC) sẽ được liên kết qua một Message Broker là ActiveMQ Điều này cho phép để gửi dữ liệu danh sách đen giữa các BFS và BFC một cách không đồng bộ Điều này rất hữu ích cho việc tách bạch giữa BFS và BFC Quan trọng nhất, sử dụng phương pháp đảm bảo thông điệp không bao giờ bị mất trong trường hợp một trong những BFC hoặc BFS bị lỗi ActiveMQ cho phép tạo ra hàng đợi (queue) một cách nhanh chóng, không cần khởi động lại ứng dụng
Hình 4.4: Ví dụ các hàng đợi được sử dụng trong hệ thống Hình 4.4 là giao diện quản lý của ActiveMQ Chúng ta có 6 hàng đợi ứng với một BFS và 5 BFC trong hệ thống BFS sẽ lắng nghe “company_request” và gửi thông điệp về 5 hàng đợi của 5 BFC
Để truyền danh sách đen của công ty đến hệ thống Bouncer-Filtering-Service (BFS), người tạo đã thiết lập một hàng đợi cho BFS BFS sẽ liên tục lắng nghe các thông điệp được thêm vào hàng đợi này Mỗi thông điệp trong hàng đợi bao gồm thông tin danh sách đen của công ty cần truyền tới BFS.
- Tên công ty, tên này dùng để cấu hình mạng lưới danh sách liên kết của các công ty đối tác
- Dữ liệu của danh sách đen dưới dạng Mergeable Counting Bloom Filter
- Thời gian logical mới nhất của BSC
Mỗi BSC cũng sẽ lắng nghe một hàng đợi riêng, ứng với tên công tên công ty để nhận thông điệp Tên hàng đợi sẽ được cấu hình trong file cấu hình cả BFS và BFC Điều này cho phép hệ thống có thể thêm một công ty thành viên mới mà chỉ cần cập nhập cấu hình
Ngoài ra, BFC còn cung cấp một số giao diện lập trình ứng dụng (API) để phục vụ cho nhu cầu tương tác và tích hợp của người dùng, bao gồm nhà phát triển, quản trị viên BFC hoặc các hệ thống khác.
Bảng 4.2 Các api được hỗ trợ bởi BCS
STT URL Phương Thức Chức năng
Gửi danh sách đen và thời gian logical hiện tại tới BFS
GET Kiểm tra xem phần tử có thể nằm trong danh sách đen
3 /api/v1/blacklist POST Thêm 1 phần tử vào danh sách đen
POST Upload 1 danh sách đen dưới dạng CSV
Vector clock
Trong hệ thống phân tán, thời gian của mỗi nút, tiến trình (node/process) là khác nhau Ngoài ra do độ trễ của mạng, chúng ta không ta không thể dựa vào thời gian thực của hệ thống để xác định thứ tự của các sự kiện xảy ra trong hệ thống
Tác giả áp dụng vector clock để truy vấn sự đóng góp của từng thành viên trong hệ thống và truy vấn lại lịch sử các sự kiện đã xảy ra Ở BFS, sẽ lưu trữ đồng hồ logical của chính nó và của tất cả các BFC trong mạng lưới chia sẻ: [BFS, BFC1, BFC2 BFCn] Mỗi khi BFS tổng hợp và gửi lại danh sách đen kèm với danh sách thời gian logical của chính BFS và BFC đối tác đó mà thôi Ở BFC, nó cũng lưu trữ thời gian logical công ty đối tác và của BFS Khi gửi danh sách đen, nó sẽ tăng thời gian logical lên 1 và gửi lại BSF.
Bài toán chuẩn hóa dữ liệu đầu vào
Định dạng dữ liệu số điện thoại mỗi công ty sẽ khác nhau Ví dụ như “097 956 1161”, “+84 97 956 1161”, “(+84) 97 956 1161”, “97 956 1161” Bài toán cần giải quyết là chuẩn hóa số điện thoại trước khi đưa vào danh sách đen Giải pháp là chúng ta cần làm chuẩn định dạng của từng tổ chức tài chính, trước khi đưa nó vào danh sách đen
Mỗi tổ chức tài chính có một hệ thống riêng để vận hành quá trình hoạt động và quản lý danh sách đen riêng Bloom Filter Client cần hỗ trợ việc tích hợp với hệ thống riêng của từng tổ chức Tác giả đề xuất hai giải pháp:
- Hệ thống của tổ chức tài chính tích hợp trực tiếp với các apis ở mục 4.3.2 như api: tải danh sách đen từ file csv vào BFC
- BFC có một cơ sở dữ liệu riêng để lưu trữ danh sách đen Các công ty có thể dùng một tiến trình Trích xuất, chuyển đổi, tải (Extract Transform, Load) để đồng bộ dữ liệu của cơ sở giữ liệu giữa tổ chức tài chính và cơ sở dữ liệu của BFC
Bảo mật hệ thống
Hệ thống phải đảm bảo là hackers dù có có được cũng không đọc được dữ liệu Chúng ta phải bảo mật hàm băm bằng cách chia sẻ hàm băm qua một kênh khác như email, ftp…Hàm băm cũng cần cập nhật thường xuyên và chia sẻ lại cho các thành viên cùng sử dụng trong hệ thống
Ngoài ra chúng ta cần phải bảo mật những thành phần của hệ thống như Bloom Filter Server (BFS), Bloom Filter Client(BFC), Message Broker
BFS và BFC kết nối trao đổi với nhau qua Message Broker, do đó việc bảo mật Message Broker trở lên quan trọng Tác giả đề xuất những giải pháp sau:
- Bật Transport Layer Security (TLS/SSL) khi liên lạc giữa BFS, BFC và message broker nhằm mã hóa dữ liệu khi truyền dữ liệu
- Bật xác thực/ủy quyền (authentication/authorization) cho message broker
ActiveMQ hỗ trợ xác thực bằng phương thức LDAP, JAAS, và phần xác thêm có thể thay đổi được và cấp phát quyền truy cập vào hàng đợi/chủ đề
- Giới hạn quyền truy cập bằng tường lửa Cân nhắc sử dụng mạng riêng ảo
(virtual private networks) để kết nối an toàn qua các mạng không đáng tin cậy
BFC có mở một số kết nối (apis) để tích hợp với hệ thống nội tại của từng công ty, vì vậy chúng ta có thể áp dụng phương pháp bảo mật cho BFC tương tự cho message broker: bật Transport Layer Security (TLS/SSL), xác thực/ủy quyền, sử dụng mạng riêng ảo
Khả năng chịu lỗi
Bloom Filter Client không gửi danh sách đen đúng thời gian
Trường hợp này xảy ra khi Bloom Filter Client (BFC) không gửi danh sách đen ở những thời gian logic định trước Trong trường hợp này nếu Bloom Filter Server (BFS) đang cấu hình ở chế độ bật bất động bộ, thì hệ thống vẫn sẽ chạy ổn trong giới hạn epsilon được cấu hình trước Tuy nhiên khi thời gian hệ thống vượt qua giới hạn này, thì hệ thống sẽ không vận hành được nữa
Để giải quyết vấn đề tắc nghẽn gửi email, BFS sử dụng tiến trình chạy định kỳ (cron job) để phát hiện và xử lý các công ty chưa gửi Tiến trình này sẽ quét và xác định các công ty bị tắc nghẽn bằng cách tổng hợp danh sách đen gần nhất của các công ty bị tắc nghẽn với dữ liệu từ các đối tác Sau đó, hệ thống sẽ gửi lại email cho các đối tác bị ảnh hưởng.
Bloom Filter Server bị sập
Bloom Filter Server nắm giữ một vai trò quan trọng trọng hệ thống Nếu BFS bị sập, toàn bộ hệ thống sẽ không vận hành được BFC tuy vẫn có thể gửi thông điệp qua các hàng đợi, nhưng chả có BFS nào để xử lý cả Do đó, chúng ta cần có một cơ chế để tránh và xử lý khi vấn xảy ra
Tác giả đề xuất một máy chủ dự phòng cho BFS và một cơ chế theo dõi và cảnh bảo khi BFS đột ngột sập Chúng ta có thể sử dụng một số công cụ như Prometheus (https://prometheus.io), là một công cụ thu thập thông số (cpu, bộ nhớ, lưu trữ, IO, độ trễ của mạng, lưu lượng mạng) và gửi về một nguồn qua giao thức http Ở BFS, ta sẽ thêm Prometheus như một thư viện, sau đó chúng ta có thể cài đặt một công cụ Grafana (https://grafana.com) Grafana là một công cụ thập thông số được gửi từ BFS bằng Prometheus và hiển thị, cung cấp các biểu đồ và tạo cảnh báo Về máy chủ dự phòng, chúng ta có thể triển khai một máy chủ dự phòng luôn luôn chạy song song với BFS chính Phương pháp này sẽ phải luôn tốn tài nghiên cho máy chủ dự phòng
BFS có thể được triển khai trên Kubernetes, một hệ thống nguồn mở quản lý và triển khai ứng dụng trong môi trường container Container là phương pháp đóng gói và chạy ứng dụng chuẩn hóa cùng với phụ thuộc cần thiết Kubernetes tự động triển khai, quản lý và mở rộng ứng dụng container, quản lý tài nguyên máy chủ, phiên bản ứng dụng khác nhau và phục hồi lỗi tự động BFS đóng thành container và triển khai trên Kubernetes, tận dụng dữ liệu được lưu trên Redis để phục hồi mà không gặp sự cố.
Bloom Filter Client bị sập
Trong trường hợp BFC bị sập, BFC cũng không gửi danh sách cập nhập, và nó cũng sẽ không nhận thông điệp danh sách đen từ đối tác do BFS trả về Với vấn đề BFC không gửi danh sách đen, chung ta có thể giải quyết như 4.4.1 là BFS có một tiến trình chạy định kỳ để xử lý tắc nghẽn cho toàn bộ hệ thống Về khôi phục BFC, chúng ta có thể áp dụng giải pháp như phần 4.4.2 là theo dõi và cảnh báo, máy chủ dự phòng hoặc triển khai Kubernetes.
Trường hợp dữ liệu danh sách đen lớn
Trường hợp này xảy ra khi trong quá trình hoạt động, dữ liệu danh sách đen của các công ty sẽ tăng lên theo thời gian Điều này sẽ làm ảnh hưởng tăng tỷ lệ dương tính giả của Bloom Filter, giảm tính đúng đắn của hệ thống Trong trường hợp này, chúng ta có thể ước lượng chiều dài của mảng dữ liệu của Bloom Filter nhiều hơn hiện tại để dự trù cho tương lai Nhưng đó chưa phải giải pháp hoàn toàn tối ưu Vì sau một thời gian vận hành, hệ thống vẫn sẽ gặp lại vấn đề như trên Tác giả đề xuất một cơ chế để Bloom Filter Client (BFC) gửi số phần tử trong danh sách đen định kỳ về Bloom Filter Server (BFS) BFC sẽ cấu hình sẵn một ngưỡng tỷ lệ dương tính giả Nếu tỷ lệ dương tính giả lớn hơn ngưỡng này, hệ thống sẽ bắt đầu lại từ đầu BSF và BSC cần tăng chiều dài mảng dữ liệu hợp lý Sau đó các BFC xây dựng một
Mergeable Counting Filter (mergeCBF) mới với chiều dài mảng mới, và gửi lại mergeCBF và timestamp cho BFS.
Đánh giá giải pháp
Tập dữ liệu và phương pháp đánh giá
Tác giả sẽ sử dụng dữ liệu danh sách đen số điện thoại mẫu bằng cách sinh ra một file csv với những số điện thoại ngẫu nhiên
Trong luận văn này, học viên sẽ lần lượt khảo sát về dung lượng lưu trữ và thời gian kiểm tra số điện thoại của Mergeable Counting Bloom Filter với nhưng phương pháp lưu danh sách đen vào cơ sở dữ liệu Cơ sở dữ liệu được sử dụng là PostgreSQL 11.12, compiled by Visual C++ build 1914, 64-bit Cấu hình của MergeCBF là dương tính giả la 0.001, số mảng bit g là 16 Tác Cấu hình hình máy tính tác giả sử dụng để khảo sát như bảng dưới
Bảng 4.3 Cấu hình máy tính để khảo sát
Hệ điều hành Microsoft Windows 11 Home Single
Language Phiên bản hệ điều hành 10.0.22621 Build 22621
CPU Intel(R) Core(TM) i7-8750H CPU @
2.20GHz, 2201 Mhz, 6 Core(s), 12 Logical Processor(s)
PostgreSQL 11.12, compiled by Visual C++ build
