Thiết kế thuật toán bộ nhớ đệm riêng để xử lý dữ liệu hết hạn

Thiết kế thuật toán bộ nhớ đệm riêng để xử lý dữ liệu hết hạn
Chúng tôi nghiên cứu bộ nhớ đệm client-server của dữ liệu với thời gian
hết hạn. Mặc dù là thúc đẩy bởi khả năng bộ nhớ đệm trong các ứng dụng viễn
thông, nhưng công việc của chúng tôi là mở rộng sang trường hợp tổng quát của
bộ nhớ đệm dữ liệu đã được biết đến là thời gian hết hạn. Hướng tới mục tiêu
này, chúng tôi thiết kế riêng thuật toán bộ nhớ đệm để xem xét dấu thời gian hết
hạn. Tiếp theo, chúng ta xem xét mô hình client-server khác nhau và cách máy
chủ nâng cấp bộ nhớ đệm cho máy khách. Cuối cùng, chúng tôi thực hiện
nghiên cứu mô phỏng để đánh giá hiệu quả thực nghiệm của một loạt các chiến
lược quản lý một bộ nhớ cache đơn độc lập của máy chủ và quản lý lưu trữ
trong một thiết lập client-server.
1. Giới thiệu
Bộ nhớ đệm tại các điểm client thường được thực hiện trong hệ thống
client – server chủ để giảm cả việc tải cơ sở dữ liệu và lưu lượng mạng. Một
loạt các cơ chế, chẳng hạn như cập nhật máy chủ, được sử dụng để đảm bảo tính
thống nhất bộ cache. Trong bài báo này, chúng tôi sử dụng nhãn thời gian hết
hạn để thống bộ nhất nhớ đệm. Nhãn thời gian hết hạn được sử dụng bởi các
dịch vụ tên miền để thúc đẩy tính thống nhất của tên phân giải và chúng là một
chủ đề hiện tại của nghiên cứu về bộ nhớ đệm web . Cả hai ứng dụng cho phép
một mức độ nhất định của sự không thống nhất dữ liệu kể từ thời điểm hết hạn
mà không được biết một cách chắc chắn trong cả hai trường hợp. Trong ứng
dụng của chúng tôi, thời gian hết hạn được biết một cách chắc chắn.
Chúng tôi sử dụng nhãn thời gian hết hạn để mô hình hóa việc định
tuyến các cuộc gọi điện thoại trong dịch vụ điện thoại phụ thuộc thời gian. Ví
dụ, dịch vụ số đơn cho phép khách hàng được tiếp cận với một số lượng phổ
quát duy nhất mà các định tuyến dựa trên thời gian trong ngày. Số duy nhất là
một số lượng hợp lý mà được phiên dịch sang một địa chỉ vật lý dựa trên thời
gian dự đoán. Sự phụ thuộc thời gian cũng phổ biến ở dịch vụ số 800 trong đó
một client có thể, ví dụ muốn định tuyến những cuộc gọi đến một văn phòng
New York cho đến 4:00, đến văn phòng Dallas 4-7 PM, và một văn phòng Los
Page 1

Thiết kế thuật toán bộ nhớ đệm riêng để xử lý dữ liệu hết hạn
Angeles sau 07:00. Đối với các dịch vụ này, bản ghi cơ sở dữ liệu liên quan đến
số đã gọi chứa đựng thuật toán cập nhật bản dịch của nó cho một số vật lý cả
ngày.
Sự truyền con số được duy trì trong một cơ sở dữ liệu mạng được gọi là
Service Control Point (SCP)(điểm kiểm soát dịch vụ). Hiện tại có 43 SCP trên
khắp Hoa Kỳ và Canada. Cung cấp dịch vụ trên toàn quốc, mỗi SCP chứa một
bản sao đầy đủ của các cơ sở dữ liệu dịch và được dành riêng để phục vụ một
bộ thử đặt thiết bị chuyển mạch điện thoại. Mặc dù kiến trúc hiện tại là đủ để tải
lưu lượng hiện nay, nhưng sự gia tăng đáng kể sẽ yêu cầu nhân rộng thêm.
Trong tương lai, chúng ta mong chờ sự tăng trưởng có cân nhắc trong việc tải
khi những con số 800 mới được thêm vào rút gọn con số được ban hành.
Nhân rộng để xử lý tải trọng gia tăng và bản có thể trở thành một giải pháp tốn
kém. Trong bài báo này, chúng tôi khám phá bộ nhớ đệm với thời gian gán nhãn
hết hạn (của client) trong việc giảm lưu lượng mạng và việc tải cơ sở dữ liệu
trong khi vẫn đảm bảo tính nhất quán dữ liệu. Các nhãn thời gian hết hạn nắm
bắt được sự phụ thuộc thời gian của quá trình dịch số trong dịch vụ điện thoại.
Trong suốt bài báo này, chúng tôi giả định quá trình dịch bộ nhớ cache
không phải toàn bộ các bản ghi cơ sở dữ liệu. Chúng tôi cũng giả định rằng
không có thông tin cập nhật bên ngoài cơ sở dữ liệu. Ngay cả trong trường hợp
không có bản cập nhật cơ sở dữ liệu bên ngoài, dữ liệu lưu trữ có thể trở nên lỗi
thời vì phụ thuộc thời gian của trình dịch. Bất cứ khi nào một bản dịch được
lưu lại, chúng tôi có thời gian mà con số logic liên quan dự kiến sẽ được lên lịch
nhận được bản dịch tiếp theo của nó. Đây là thời gian hết hạn của sản phẩm lưu
trữ. Đối với những dịch vụ phụ thuộc thời gian, thời gian hết hạn được biết một
cách chắc chắn (trong trường hợp không có bản cập nhật cơ sở dữ liệu), vì vậy
chúng tôi có thể nhớ (cache) và vẫn đảm bảo bản dịch những con số thích hợp
bằng cách truy vấn cơ sở dữ liệu nếu một bản dịch được lưu trữ đã hết hạn. Do

đó, chúng ta có thể thực thi các yêu cầu chất lượng trong khi vẫn cho phép
client quản lý lưu trữ riêng của chúng. Sử dụng nhãn thời gian hết hạn cho phép
Page 2


Thiết kế thuật toán bộ nhớ đệm riêng để xử lý dữ liệu hết hạn
xác minh thống nhất bộ nhớ cache địa phương và do đó tránh sự nhúng cơ sở dữ
liệu.
Một thay thế cho bộ nhớ đệm với thời gian gán nhãn hết hạn là để cache
toàn bộ hồ sơ (bản ghi) cơ sở dữ liệu và yêu cầu client để làm các tính toán cần
thiết để xác định số lượng bản dịch. Trong khi loại bỏ việc nhu cầu về thời gian
hết hạn, phương pháp này đòi hỏi giả định mạnh hơn về khả năng của các thiết
bị phía khách hàng và về sự sẵn sàng của khách hàng để cho phép sử dụng tài
nguyên máy tính. Hơn nữa, việc tải về toàn bộ hồ sơ cơ sở dữ liệu có thể không
nhất thiết phải cung cấp một sự cắt giảm tương tự trong các truy vấn đến server
bởi vì các hồ sơ (bản ghi) cơ sở dữ liệu có thể là lớn so với bản dịch con số đơn
giản.
Trong bài báo này, chúng tôi thiết kế thuật toán bộ nhớ đệm riêng để xử
lý dữ liệu hết hạn. Chúng tôi cho thấy một biến của thuật toán đã sử dụng gần
đây (LRU) thể chứng minh LRU chiếm ưu thế, và chúng tôi làm mô phỏng để
so sánh hiệu suất thực nghiệm của các thuật toán khác nhau trong sự hiện diện
của nhãn thời gian hết hạn. Cuối cùng, chúng tôi xem xét tác động của thông
điệp cập nhật từ server định kỳ để làm mới dữ liệu đã hết hạn.
2.Thuật toán trong việc duy trì bộ nhớ đệm đơn giản
Trong hai phần tiếp theo, chúng ta xem xét việc duy trì một bộ nhớ cache
duy nhất trong sự hiện diện của nhãn thời gian hết hạn. Vấn đề cơ bản là một
biến của vấn đề bộ nhớ đệm cổ điển trong đó chúng ta có một lượng nhỏ bộ nhớ
nhanh và nhớ chậm lớn hơn, và chúng tôi muốn xác định các mục để giữ trong
bộ nhớ nhanh để phục vụ tốt nhất một dòng yêu cầu gửi đến. Về vấn đề của
chúng tôi, bộ nhớ đệm client cung cấp bộ nhớ tốc độ nhanh, và cơ sở dữ liệu

mạng cung cấp “bộ nhớ chậm”, nhưng chúng tôi cũng cần kết hợp nhãn thời
gian hết hạn, mà không có mặt trong các vấn đề cũ.
2.1 Tóm tắt thuật toán bộ đệm – không có nhãn thời gian hết hạn
Các vấn đề bộ nhớ đệm cổ điển được phát biểu như sau. Chúng tôi có
một cơ sở dữ liệu với n ITEM , một bộ nhớ cache mà có thể lưu trữ k ITEM,
Page 3


Thiết kế thuật toán bộ nhớ đệm riêng để xử lý dữ liệu hết hạn
và một chuỗi các yêu cầu cho các ITEM trong cơ sở dữ liệu. Khi một ITEM
được yêu cầu trong bộ nhớ cache, chúng tôi không có sự hao tổn gì , nhưng khi
ITEM đó được yêu cầu không có trong bộ nhớ cache, chúng ta phải đưa nó vào
bộ nhớ cache với sự tiêu tốn mất một đơn vị. Khi một ITEM mới sẽ được đưa
vào một bộ nhớ cache đầy đủ, một thuật toán bộ nhớ đệm xác định các ITEM
hiện có sắp bị loại để thích ứng với cái mới.
Khi thuật toán phải đưa ra quyết định này mà không có sự nắm bắt về yêu
cầu tiếp theo, các thuật toán được gọi là một thuật toán online (trực tuyến). Các
vấn đề bộ nhớ đệm là một vấn đề trực tuyến cổ và một bản tóm tắt tuyệt vời của
kết quả lý thuyết được trình bày trong [5]. Ví dụ về các thuật toán bộ nhớ đệm
nổi tiếng là:
LRU: Gỡ bỏ các item trong bộ nhớ cache đã được sử dụng gần đây nhất;
LFU: Gỡ bỏ các item trong bộ nhớ cache đã được sử dụng thường xuyên nhất;
LRU-x: Nếu tất cả các mục đã được đọc ít nhất là x lần kể từ khi chèn vào bộ
nhớ cache, thì bỏ mục đã được sử dụng gần đây nhất. Nếu không thì bỏ mục
truy cập ít hơn x lần đã được sử dụng gần đây nhất. (Xem [20].)
FF: Gỡ bỏ các mục trong bộ nhớ cache có yêu cầu tiếp theo là bước tiến xa
nhất;
RAND: Chọn mục để bỏ ngẫu nhiên trong số các mục trong bộ nhớ cache.
Các thuật toán LRU, LRU-x, LFU và RAND tất cả là các thuật toán
online, trong khi FF được cho là một thuật toán offline bởi vì nó sử dụng các

thông tin về các yêu cầu trong tương lai. Belady cho thấy FF là thuật toán
offline tối ưu bởi vì nó đảm bảo để giảm thiểu số lượng các lỗi bộ nhớ cache
cho bất kỳ luồng truyền yêu cầu nhất định. Trong khi nó không có ý nghĩa để
xem xét sử dụng các thuật toán tùy chỉnh offline cho hầu hết các ứng dụng (bao
gồm cả chúng ta), nó rất hữu ích như một điểm so sánh. Do đó, thay vì chỉ đơn
giản là quan sát số lượng hoặc tỷ lệ phần trăm của số truy cập bộ nhớ cache,

Page 4


Thiết kế thuật toán bộ nhớ đệm riêng để xử lý dữ liệu hết hạn
chúng ta có thể quan sát cách một quá trình trực tuyến thực hiện liên quan đến
các thuật toán tốt nhất có thể.
2.2 Bộ nhớ cache với thời hạn thời gian gán nhãn
Khi xem xét bộ nhớ đệm trong sự có mặt của nhãn thời gian hết hạn, điều
đầu tiên cần lưu ý là tất cả các thuật toán trực tuyến thảo luận trong phần 2.1
vẫn được áp dụng. Chúng tôi chỉ đơn giản là bỏ qua sự hết hạn về thời gian và
áp dụng các thuật toán như đã nêu. Tuy nhiên, bây giờ là trường hợp mà một
phiên bản hết hạn của một item được yêu cầu không có thể mang lại một lần
truy cập cache và theo cách này không thể được sử dụng sau khi nó hết hạn. Do
đó, một yêu cầu phải chịu một lỗi trừ khi ITEM được yêu cầu trong bộ nhớ
cache và chưa hết hạn. Trong sự hiện diện của nhãn thời gian hết hạn, chúng ta
xem xét một thuật toán trực tuyến đơn giản, được FTD gọi là, mà quá trình loại
bỏ nó chỉ dựa vào thời gian hết hạn.
FTD: Gỡ bỏ các ITEM trong bộ nhớ cache mà là cái đầu tiên để tiêu diệt
Các thuật toán offline tối ưu trong sự hiện diện của nhãn thời gian hết hạn
là một sửa đổi của FF mà chúng ta gọi là FF-ET.
FF-ET: Nếu có các mục trong bộ nhớ cache được hết hạn vào lần sử
dụng tiếp theo, hãy chọn một trong số chúng để loại bỏ từ bộ nhớ cache. Nếu
không, hãy loại bỏ cái mục mà lần sử dụng tiếp theo xa nhất.

Định lý 1. FF-ET là thuật toán offline tối ưu trong sự hiện diện của
thời gian hết hạn.
Bằng chứng: Bằng chứng đơn giản là dựa trên thực tế là chúng ta có thể
loại bỏ sự hết hạn về thời gian bằng cách sử dụng các khái niệm về phiên bản.
Một ITEM mà hết hạn trước lần sử dụng tiếp theo của nó chỉ đơn giản là một
phiên bản của bản ghi (hồ sơ) mà không bao giờ yêu cầu một lần nữa. Khi
chúng tôi thực các hiện sửa đổi này, chúng tôi áp dụng FF với các trường hợp
không có thời gian hết hạn.
2.2.1. Các thuật toán bộ nhớ đệm phân cấp theo từng tầng

Page 5


Thiết kế thuật toán bộ nhớ đệm riêng để xử lý dữ liệu hết hạn
Bây giờ, chúng ta sẽ tìm hiểu cách thức chúng ta có thể chỉnh thuật toán
LRU và LRU-x online(trực tuyến) mà thể hiện tốt hơn khi dữ liệu có dấu thời
gian hết hạn. Mod-ification với các thuật toán offline cho thấy các mục hết hạn
sử dụng càng sớm càng tốt là một ý tưởng hay. Trên thực tế, dữ liệu đã hết hạn
trong bộ nhớ cache có hiệu quả làm giảm kích thước của bộ nhớ cache, vì dữ
liệu quá hạn sử dụng không bao giờ có thể mang lại một lần truy cập (hit) cache.
Vì một ITEM sẽ không được sử dụng trong một hình thức hết hạn, LRU tích
hợp sẵn trong hướng loại bỏ các dữ liệu hết hạn sử dụng từ bộ nhớ cache.
Không có ITEM nào có thể duy trì nhiều hơn k lỗi lần (k là kích thước bộ nhớ
cache) sau khi hết hạn của nó. LRU-x không có cơ chế sẵn có, và nó là đơn giản
để xây dựng ra những ví dụ trong đó dữ liệu hết hạn sử dụng vẫn còn trong bộ
nhớ cache vô thời hạn
Nếu chúng tôi hoạt động theo giả thiết rằng dữ liệu đã hết hạn cần được
loại bỏ từ cache ở lần đầu tiên, sau đó những biến hai tầng của các thuật toán cơ
bản của chúng tôi xuất hiện. Ý tưởng là để phân vùng bộ nhớ cache thành dữ
liệu đã hết hạn và làm mới, tại thời điểm mà một sự loại bỏ xảy ra. Nếu có dữ

liệu hết hạn, chúng tôi áp dụng chiến lược cơ bản trong phần hết hạn của bộ nhớ
cache. Nếu không có số liệu hết hạn, chúng tôi chỉ đơn giản là áp dụng các thuật
toán tiêu chuẩn. Chúng ta gọi là thuật toán 2 tầng này bởi vì chúng tôi áp dụng
các thuật toán cơ bản, theo LRU, tầng đầu tiên là các mục hết hạn sử dụng trong
bộ nhớ cache. Trong trường hợp không có dữ liệu không mong muốn cập nhật
từ máy chủ, áp dụng một thuật toán bộ nhớ đệm đầy đủ với các ITEM hết hạn là
quá mức cần thiết, hiệu suất là không phân biệt cùng đã hết hạn ITEM chúng tôi
loại bỏ và chúng ta để chờ đợi loại bỏ các mặt hàng hết hạn hoặc loại chúng
ngay khi hết hạn, các điểm quan trọng chỉ đơn giản là để loại các ITEM hết hạn
trước những ITEM mới. Trong phần sau, chúng tôi cho phép các máy chủ cập
nhật định kỳ các ITEM hết hạn sử dụng trong bộ nhớ cache. Trong bối cảnh đó,
dễ dàng áp dụng một chiến lược xóa bỏ hiệu quả, ngay cả với các ITEM hết

Page 6


Thiết kế thuật toán bộ nhớ đệm riêng để xử lý dữ liệu hết hạn
hạn. Chính vì lý do này, chúng tôi xác định các thuật toán hai tầng như chúng ta
có.
Việc buộc các ITEM hết hạn bị loại bỏ đầu tiên dường như là một thay
đổi nhỏ mà chắc chắn sẽ tốt hơn (trội hơn) các thuật toán đơn tầng ban đầu. Tuy
nhiên, nó không nhất thiết phải đúng là ref-erentially loại bỏ các mục hết hạn
cải thiện hiệu suất. Hình 1 cung cấp một ví dụ trong đó biến hai tầng của LRU2 thực hiện kém hơn so với phiên bản lớp (tầng) đơn. Nó chỉ ra rằng hai tầng
LRU-x có thể cho phép một biến bất thường của Belady nơi tăng kích thước
hiệu quả của bộ nhớ cache bằng cách loại bỏ các mục hết hạn sử dụng thực sự
có thể làm suy giảm hiệu suất.

Hình : Ví dụ nơi loại bỏ những mục hết hạn LRU-2
Ví dụ trong hình 1 sử dụng các ITEM hết hạn sử dụng có hiệu quả giảm
kích thước của bộ nhớ cache cho các thuật toán đơn tầng và trong thực tế, phục

vụ để chứng minh cách LRU-2 có thể biểu hiện bất thường của Belady thậm chí
không có nhãn thời gian hết hạn.

Page 7


Thiết kế thuật toán bộ nhớ đệm riêng để xử lý dữ liệu hết hạn
Các biến hai tầng của LRU không biểu hiện hành vi bất thường này. Chúng ta
nói rằng thuật toán A cao hơn B nếu, với mỗi chuỗi yêu cầu, một sản lượng ít
nhất bằng nhiều lượt truy cập bộ nhớ cache B. Với định nghĩa này, chúng ta có
thể chứng minh rằng hai tầng LRU ưu thế hơn LRU đơn tầng. Bằng chứng của
chúng ta về kết quả này là khá dài, vì vậy chúng tôi phác thảo ý tưởng và mời
độc giả xem [7] cho đầy đủ bằng chứng.
Định lý 2. LRU hai tầng chiếm ưu thế hơn LRU đơn tầng.
Ý tưởng của dẫn chứng: Kết quả được chứng minh chỉ ra rằng, đối với bất kỳ
chuỗi Request, các ITEM mới trong bộ nhớ cache mà có được từ việc áp dụng
LRU là một tập hợp con của các ITEM mới mà kết quả từ việc áp dụng LRU
hai tầng. Vì các ITEM mới này là những cái duy nhất có thể tạo ra lượt truy
cập bộ nhớ cache, điều này đảm bảo rằng phiên bản hai tầng phải thực hiện nhỏ
nhất cũng như (bằng) LRU.
Chúng tôi chứng minh mối quan hệ tập hợp con bằng quy nạp. Chúng tôi
thấy rằng khi chúng ta bắt đầu với bộ nhớ cache ban đầu như nhau và dịch vụ
luồng yêu cầu tương tự với mỗi thuật toán với các thuộc tính theo sau, nắm giữ
sau khi mỗi hết hạn hoặc yêu cầu:
1) các ITEM mới trong bộ nhớ cache LRU cũng có trong bộ nhớ cache LRU
hai tầng,
2) các ITEM mới trong bộ nhớ cache LRU gần đây nhất được sử dụng chính
xác là các ITEM mới trong bộ nhớ cache LRU hai tầng. Chúng tôi gọi những
cái này là tập con và có tính recency. Thuộc tính recency đảm bảo rằng nếu
chúng tôi loại một ITEM mới từ LRU cache hai tầng, thì sau đó nó cũng là

một ITEM được loại ra khỏi bộ nhớ cache LRU, hoặc các ITEM đã bị trục xuất
không còn chứa trong bộ nhớ cache LRU. Như vậy, thuộc tính recency duy trì
thuộc tính tập hợp con và con thuộc tính đảm bảo kết quả.
Chúng ta có thể thực hiện các thuật toán theo từng cấp một bước xa hơn
bằng cách phân vùng bộ nhớ cache vào ba tầng tương ứng với: Các ITEM đã
hết hạn; những ITEM được dự đoán sẽ hết hạn trước lần sử dụng tiếp theo của
Page 8


Thiết kế thuật toán bộ nhớ đệm riêng để xử lý dữ liệu hết hạn
chúng ; và các ITEM được dự đoán là làm mới tại lần sử dụng tiếp theo của
chúng. Ở đây, chúng tôi áp dụng quá trình cơ bản đầu tiên cho các ITEM hết
hạn bên cạnh các ITEM dự đoán sẽ hết hạn, và cuối cùng là các ITEM được dự
báo làm mới lại.
Chúng tôi dự đoán các ITEM hết hạn sử dụng giả định rất đơn giản
(LRU cơ bản) rằng tương lai gần được dự đoán bởi thời gian quá khứ gần đây là
tốt nhất. Tại bất kỳ thời điểm t, chúng ta có thể dự đoán thời gian để lần yêu cầu
tiếp theo sử dụng thời gian kể từ yêu cầu cuối cùng. Nếu t r là thời gian cho một
ITEM được yêu cầu cuối cùng, ∆= t – tr là thời gian trôi qua kể từ yêu cầu cuối
cùng. Chúng tôi cho rằng thời gian này sẽ trôi qua trước khi yêu cầu tiếp theo và
dự đoán yêu cầu tiếp theo xảy ra và o thời điểm t+∆. Nếu t+∆ là thời gian sau
khi hết hạn của sản phẩm lưu trữ, sau đó chúng tôi nói rằng nó được dự đoán sẽ
hết hạn. Chiến lược ba tầng này là phần mở rộng rõ ràng nhất của chiến lược hai
tầng, nhưng kết quả thực nghiệm trong phần tiếp theo cho thấy rằng nó không
cải thiện sau khi chiến lược hai tầng đơn giản.
3. Kết quả mô phỏng bộ nhớ cache đơn
Trong phần này, chúng tôi tập trung vào việc thực hiện thực nghiệm của
các chiến lược bộ nhớ đệm khác nhau trong sự hiện diện về thời gian hết hạn.
Chúng tôi đo hiệu suất bộ nhớ đệm bằng số lượt truy cập bộ nhớ cache được tạo
ra bởi mỗi quá trình. Mục tiêu chính của chúng tôi là đánh giá hiệu quả hoạt

động của một, hai, và quá trình bộ nhớ đệm ba tầng tương đối với nhau và liên
quan đến các diễn đàn chiến lược tối ưu FF-ET. Để làm những so sánh này,
chúng tôi mô phỏng hoạt động của các quá trình khác nhau với một mô hình
phát triển bằng cách sử dụng CSIM [8] môi trường mô phỏng sự kiện rời rạc.
3.1 Mẫu client
Vì chúng tôi không nghiên cứu thời gian, chúng tôi áp dụng một mô hình
đơn giản trong đó client ra một yêu cầu trong mỗi đơn vị thời gian. Client có
một bộ nhớ cache có thể chứa k mục và nó yêu tạo cầu các mục theo một phân
bố xác suất Zipf [16]. Phân phối Zipf là một phân phối lệch đặc trưng bởi một
Page 9


Thiết kế thuật toán bộ nhớ đệm riêng để xử lý dữ liệu hết hạn
tham số α ≥ 0. Giá trị cao hơn của α chỉ phân phối lệch nhiều hơn. Nghiên cứu
gần đây [9, 12] đã chỉ ra rằng việc phân phối Zipf cung cấp dữ liệu truy cập web
quan sát thích hợp hơn. Dựa trên quan sát hạn chế của chúng ta về dữ liệu độc
quyền, chúng tôi tin rằng điều này cũng có thể đúng đối với điện thoại

Client bắt đầu với một bộ nhớ cache trống và lấp đầy bộ nhớ cache như lỗi trên
yêu cầu . Một khi bộ nhớ cache là đầy , client lưu trữ sử dụng một trong các
thuật toán bộ nhớ đệm được mô tả trong phần 2. Các thuật toán cơ sở chúng ta
xem xét là LRU và LRU -2 . Chúng ta kiểm tra hiệu năng của cả hai chiến lược
thực thi sử dụng một, hai và ba tầng, như được mô tả trong phần trước. Để so
sánh rộng hơn , chúng ta thử nghiệm với FTD, RAND và thuật toán ngoại tuyến
tối ưu FF- ET . Thực thi của chúng ta về các thuật toán bộ nhớ đệm bao gồm
một điều chỉnh thực hiện nhỏ : Nếu chúng ta loại bỏ sau khi một bộ nhớ cache
nhớ kết quả đó bởi vì việc lưu trữ bản sao của phần tử được yêu cầu là hết hạn ,
chúng ta thay thế phiên bản cũ với bản dịch mới ưu tiên đến việc loại bỏ một
phần tử không liên quan. Mô tả sơ đồ mạch của kết quả thuật toán caching 3
tầng được thể hiện trong hình 2.

Để giảm thiểu những ảnh hưởng của việc khởi tạo một bộ nhớ cache trống ,
chúng tôi cho phép mô phỏng một thời gian khởi động trong khi các client hoạt

Page 10


Thiết kế thuật toán bộ nhớ đệm riêng để xử lý dữ liệu hết hạn
động như bình thường sẽ thực hiện nhưng không được theo dõi. Điều này cho
phép thời gian cho bộ nhớ cache của client để điền vào và sau đó hoạt động
trong một thời gian trước khi chúng ta bắt đầu quan sát .

3.2. mô hình dữ liệu
Chúng ta đang nghiên cứu hiệu năng bộ nhớ đệm chứ không phải hiệu năng
máy chủ , chúng ta không cần một mô hình máy chủ phức tạp . Máy chủ đại
diện cho một cơ sở dữ liệu kích thước n, và khách hang chỉ đơn giản là yêu cầu
các phần tử trong phạm vi từ 1 đến n . Độc lập với quá trình theo yêu cầu của
khách hàng là cơ chế với các dữ liệu phần tử hết hạn. Trong nghiên cứu này ,
chúng tôi giả định rằng dữ liệu hết hạn theo chu kỳ . Có nghĩa là, nếu chúng ta
xác định một khoảng thời gian , như một ngày , hết hạn sẽ xảy ra ở thời điểm
cài đặt trước trong từng thời kỳ. Cho mục đích của mô phỏng, chúng tôi xác
định độ dài thời gian và số lần mỗi phần tử hết hạn cho mỗi chu kỳ. Với thiết
lập này, thời gian hết hạn thực tế cho mỗi phần tử được lựa chọn ngẫu nhiên
trong giai đoạn. Sự ngẫu nhiên này cho phép dữ liệu của phần tử để đối xử như
nhau về số lượng lần hết hạn của chúng , nhưng khác nhau về thời gian mà sự
hết hạn xảy ra.

Page 11


Thiết kế thuật toán bộ nhớ đệm riêng để xử lý dữ liệu hết hạn

3.3. kết quả
Chúng tôi thực hiện mô phỏng để kiểm tra tính hiệu quả của các thuật toán bộ
nhớ đệm khác nhau trong nhiều hoàn cảnh . Mục tiêu của chúng tôi là: 1) để
đánh giá hiệu suất của các thuật toán bộ nhớ đệm phân tầng quan hệ với các đối
tác đơn tầng gốc của chúng , 2 ) để quan sát ảnh hưởng của các thông số như
kích thước bộ nhớ cache và tần số hết hạn. Trong mọi trường hợp, các điểm dữ
liệu được hiển thị trong các hình được dựa trên mức trung bình của 100 mô
phỏng khác nhau chạy với các thiết lập thông số cơ bản giống nhau . Các thiết
lập thông số được tóm tắt trong bảng 1 và 2 . Các thông số được in đậm được
coi là mặc định cho các trường hợp nắm giữ giá trị của các hằng số tham số liên
quan.
Hai đồ thị trong hình 3 minh họa hiệu suất của các biến thể phân tầng của LRU
và LRU -2 cho kích thước bộ nhớ cache khác nhau khi dữ liệu hết hạn hai lần
mỗi thời kỳ. Các đồ thị trong hình 4 cho thấy hiệu suất tương đối của các chiến
lược phân tầng một loạt các tần số hết hạn với kích thước bộ nhớ cache cố định
ở mức 25 . Từ những thử nghiệm chúng tôi có thể đưa ra một vài nhận xét
chung. Đầu tiên ,các phiên bản phân tầng của cả LRU và LRU -2 dường như
mang lại hiệu suất tốt hơn ở tất cả các kích thước bộ nhớ cache và tần số hết
hạn. Sự khác biệt lớn nhất ở các kích thước bộ nhớ cache nhỏ hơn và hết hạn
thường xuyên nhất. Kể từ khi có dữ liệu quá hạn sử dụng trong bộ nhớ cache nó
có hiệu quả làm giảm kích thước của bộ nhớ cache, sẽ là hợp lý hơn khi cho
rằng dữ liệu hết hạn ảnh hưởng ít hơn đến sự không cân đối của bộ nhớ đệm.
Nên nó cũng là hợp lý khi cho rằng các tác động trở nên lớn hơn khi có khá

Page 12


Thiết kế thuật toán bộ nhớ đệm riêng để xử lý dữ liệu hết hạn
nhiều dữ liệu đã hết hạn bắt nguồn từ việc hết hạn thường xuyên . Các ảnh

hưởng này mạnh hơn cho LRU -2 hơn là cho LRU . Lý do có thể là LRU -2 là ít
có khả năng loại bỏ các dữ liệu đã hết hạn từ bộ nhớ cache như chúng tôi mô tả
trong phần trước. Điều này là quan trọng bởi vì LRU-2 hai tầng không thể
chứng minh bao quát các thuật toán đơn tầng . Cuối cùng, chúng tôi lưu ý rằng
sự gia tăng lớn nhất được quan sát trong tỷ lệ truy cập của chiến lược hai tầng là
2,76% Tuy nhiên, những cải tiến ở mức vừa phải tạo nên sự chuyển dịch lên tới
23% số lượng truy cập.

Các đồ thị trong hình 3 cũng so sánh hiệu suất của phiên bản tầng của LRU và
LRU -2 với các thuật toán ẩn tối ưu FF- ET , với thuật toán loại bỏ ngẫu nhiên
RAND, và với FTD . Những con số minh họa rằng các chiến lược trực tuyến
tiếp cận hiệu suất ẩn tối ưu cho kích thước bộ nhớ cache tương đối nhỏ. Chúng
tôi quan sát hiệu suất tối ưu với bộ nhớ cache kích thước trong khoảng 50-100 .
Các kích thước này được xem xét là nhỏ hơn so với kích thước đáng kể mà các
Page 13


Thiết kế thuật toán bộ nhớ đệm riêng để xử lý dữ liệu hết hạn
chiến lược trực tuyến hiệu suất tối ưu trong trường hợp không có nhãn thời gian
hết hạn. Quan sát của chúng tôi về các thuật toán áp dụng trong các trường hợp
không có nhãn thời gian hết hạn cho thấy chiến lược trực tuyến bắt đầu để tỏ ra
hoạt động tối ưu với kích thước bộ nhớ cache trong khoảng 1000-2000 . Thực tế
là điều này xảy ra sớm hơn rất nhiều khi chúng tôi có dữ liệu hết hạn xác nhận
trực giác tự nhiên mà kiến thức về các yêu cầu tương lai là ít có giá trị khi dữ
liệu hết hạn, do đó làm giảm lợi thế của thuật toán ẩn .
Một quan sát thú vị là thuật toán FTD đơn giản thực hiện tối ưu khi kích thước
bộ nhớ cache là gần 50 . Điều này có vẻ đáng ngạc nhiên vì những gì đã biết của
tính đơn giản của chiến lược. Tuy nhiên , nó có lẽ là trường hợp khi bộ nhớ
cache đạt đến một kích thước ngưỡng, có khả năng là có ít nhất một phần tử quá
hạn sử dụng trong bộ nhớ cache và FTD đương nhiên loại bỏ phần tử hết hạn

đầu tiên . Bằng cách này, FTD có thể được xem như là một chiến lược hai tầng
tự nhiên. Hỗ trợ lời giải thích này , chúng tôi lưu ý rằng kích thước mà FTD bắt
đầu thực hiện tối ưu là 25 khi các phần tử hết hạn ba lần trong một khoảng thời
gian . Khi hết hạn thường xuyên hơn , khả năng một phần tử hết hạn trong bộ
nhớ cache tang vì vậy FTD bắt đầu hoạt động giống như một thuật toán hai tầng
tại một kích thước bộ nhớ cache nhỏ hơn.

Page 14


Thiết kế thuật toán bộ nhớ đệm riêng để xử lý dữ liệu hết hạn

Một điều thú vị là thuật toán FTD đơn giản có thể được thực hiện một
cách tối ưu khi kích thước bộ nhớ đệm nhỏ hơn 50. Điều này có vẻ ngạc nhiên
sau khi xem xét sự đơn giản của chiến lược. Tuy nhiên nó chỉ là trường hợp một
bộ nhớ đệm đạt đến kích thước tối đa, nó trở thành giống như một mặt hàng đã
hết hạn sử dụng trong bộ nhớ đệm và FTD tự nhiên không còn là mặt hàng hết
hạn đầu tiên. Bằng cách này, FTD có thể được xem như là một chiến lược hai
tầng xuất hiện tự nhiên. Bổ sung thêm cho lời giải thích, chúng ta lưu ý rằng
kích thước FTD tối ưu khi bắt đầu thực hiện là 25 trong khi item quá hạn ba lần
mỗi giai đoạn.
4. Mô hình client-server
Trong phần còn lại, chúng ta sử dụng một mô hình client-server đơn giản
để đại diện cho một nhóm client hoặc khách hàng tương tác với một cơ sở dữ
liệu mạng thông thường. Hình 5 là một minh họa cơ bản. Ở đây, chúng ta có
một tập hợp các clients truy vấn độc lập mạng cơ sở dữ liệu để có được bản
dịch. Mỗi clients có yêu cầu về profile của riêng mình và bộ nhớ đệm riêng.
Đây là những ví dụ tương tự như single-client đã nghiên cứu trước đây. Một lần
nữa, cơ sở dữ liệu có các bản ghi chứa các bản dịch vẫn có hiệu lực trong

Page 15


Thiết kế thuật toán bộ nhớ đệm riêng để xử lý dữ liệu hết hạn
khoảng thời gian xác định, và nó có một cơ chế tạo ra một dấu thời gian để
truyền tải bản dịch hiện nay vẫn có giá trị.
Bất cứ khi nào client khởi tạo một yêu cầu, địa chỉ bộ nhớ đệm của client
sẽ được tra cứu. Nếu yêu cầu của item được tìm thấy và nó chưa hết hạn, bản
dịch lưu trữ được sử dụng và không truy vấn cơ sở dữ liệu được yêu cầu. Nếu
tra cứu bộ nhớ đệm là không thành công, hoặc vì mục yêu cầu không phải là
trong mục được tìm thấy và nó chưa hết hạn, bản dịch được lưu trữ được sử
dụng và không truy vấn cơ sở dữ liệu được yêu cầu. Nếu tra cứu bộ nhớ đệm là
không thành công, hoặc item không phải là trong bộ nhớ đệm, hoặc là bản dịch
lưu trữ đã hết hạn, khách hàng truy vấn cơ sở dữ liệu và lưu trữ các bản dịch
mới. Như trước đây, một client luôn luôn lưu trữ một item mà tạo ra bộ nhớ
đệm bị bỏ qua, và nếu bỏ qua là cần thiết, nó bỏ qua việc sử dụng một trong các
thuật toán lưu trữ được mô tả trong phần 2.
Cho đến nay, điều này là hoàn toàn tương tự như mô hình bộ nhớ đệm
duy nhất mà chúng ta nghiên cứu trước đó. Tuy nhiên, trong mô hình clientserver này, chúng ta xem xét sử dụng một loạt các tùy chọn nhắn tin server kết
hợp với timestamping để thúc đẩy sự mới mẻ cho bộ nhớ đệm và giảm số lượng
các truy vấn đến máy chủ. Ý tưởng của việc xem xét tin nhắn server để nâng
cao hiệu suất bộ nhớ đệm được nhắc đến trong các ứng dụng khác nhau bởi
Acharya và các cộng sự. [1]. Các chủ đề tổng quát hơn của bộ nhớ đệm clientserver cho các hệ thống cơ sở dữ liệu được xem xét trong [10] và [11]. Trong
bài báo này, chúng tôi xem xét bốn mô hình tin nhắn server cơ bản:
•

•

(CR) Client Request: Cơ sở dữ liệu sẽ chỉ gửi bản dịch theo yêu cầu của
khách hàng. Điều này tương tự với những gì đã được thực hiện trong các

trường hợp single-client.
(ISB) Ignorant server Broadcast: Các server định kỳ phát đi các bản dịch
đã thay đổi kể từ lần phát đi cuối cùng của nó. Các client cập nhật các bản
dịch đã hết hạn ở hiện tại và truy vấn cơ sở dữ liệu trên bất kỳ bộ nhớ
đệm bị bỏ lỡ nào xảy ra giữa quá trình phát đi. Các server không có thông
tin về nội dung bộ nhớ đệm của client và chương trình phát sóng chỉ dựa
trên thông tin của các bản dịch trong cơ sở dữ liệu.
Page 16


Thiết kế thuật toán bộ nhớ đệm riêng để xử lý dữ liệu hết hạn
•

•

(KSB) Knowledgeable Server Broadcast: Server phát đi các item được
lưu trữ nhưng đã hết hạn. Các client cập nhật các bản dịch đã hết hạn ở
hiện tại và truy vấn cơ sở dữ liệu trên bất kỳ bộ nhớ đệm bị bỏ lỡ xảy ra
giữa các quá trình phát đi. Các server có thông tin về nội dung bộ nhớ
đệm của client và sử dụng thông tin này để xây dựng thông điệp của nó.
(KSU) Knowledgeable Server Unicast: Giống như KSB ngoại trừ server
sẽ gửi mỗi client một tin nhắn cá nhân chỉ với những item hết hạn trong
bộ nhớ đệm của nó.
Vì giới hạn nghiêm ngặt về thời gian của dịch vụ điện thoại, bất kỳ yêu

cầu nào không được phục vụ bởi bộ nhớ đệm là ngay lập tức gửi đến server bất
kể có hay không có tin nhắn khởi tạo của server. Bằng cách này, ba chương
trình với những thông điệp khởi tạo server có thể được xem như một mô hình
bao phủ theo yêu cầu cơ bản của. Hoặc, CR có thể được xem như là một ví dụ
điển hình của một trong ba chiến lược khác với thời gian vô hạn giữa các tin

nhắn. Các phương pháp bắt đầu với server khởi tạo tin nhắn khác nhau về số
lượng hoặc kích thước của thông điệp họ gửi nhưng không phải trong lượng
thông tin hữu ích chuyển tải đến khách hàng. Vì vậy, nếu chúng ta giả định cập
nhật tức thời để loại bỏ vấn đề thời gian , ba phương pháp không khác nhau về
hiệu suất bộ nhớ đệm. Sự khác biệt của họ nằm trong lượng thông tin server
phải lưu trữ để xây dựng thông điệp, server phải cố gắng mở rộng để xây dựng
các thông báo, lọc tổng số client phải làm gì để khai thác thông tin có liên quan
và lưu lượng truy cập mạng tạo ra.
Chiến lược của CR và ISB rất đơn giản và phân cấp theo nghĩa là các
client và server hoạt động độc lập. Mô hình ISB là một phần mở rộng đơn giản
của CR trong đó các server định kỳ gửi thông điệp cập nhật cho khách hàng
nhưng không có thông tin về nội dung bộ nhớ đệm của client. Lý do đằng sau
cách tiếp cận như vậy là server có thể làm giảm số lượng yêu cầu nó phải phục
vụ bằng cách giữ cho bộ nhớ đệm của client còn rõ rệt nhưng các client và
server vẫn có thể hoạt động độc lập. Hai phương pháp cố gắng để làm giảm
lượng thông tin phải được truyền đi bằng cách khai thác thông tin cụ thể về bộ
nhớ đệm của client. Do đó, chúng làm giảm lượng công việc mà client phải làm
Page 17


Thiết kế thuật toán bộ nhớ đệm riêng để xử lý dữ liệu hết hạn
gì để lọc tin nhắn và họ có thể làm giảm tải mạng, nhưng chúng làm tăng khối
lượng công việc trên máy chủ để xây dựng và hỗ trợ các tin nhắn có liên quan
nhiều hơn. Để thực hiện một phương pháp tiếp cận dựa trên hiểu biết, client
phải thực tế "đăng ký" nội dung bộ nhớ đệm của họ với server. Tại thời điểm
yêu cầu đến server, client cho biết có hay không có ý định lưu trữ item( điều
này cho phép các client mà không có bộ nhớ đệm) và xem item sẽ ghi đè lên
item đã hết hạn. Cơ chế này thông báo cho server khi một item được cài đặt
trong bộ nhớ đệm của item và hiệu quả ghi bộ nhớ đệm của nội dung đó với
server. Các server có thể cấm các khách hàng để bộ nhớ đệm bằng cách cung

cấp một thời gian hết hạn đã được xác định. Khi một client loại bỏ một item từ
bộ nhớ đệm, nó sẽ gửi một tin nhắn thông báo cho server. Trong khi thông báo
bỏ qua có thể không cần thiết về mặt lý thuyết, điều này sẽ giúp hạn chế số
lượng và kích thước của tin nhắn mà server phải gửi để giữ cho lưu trữ của
khách hàng còn rõ rệt, và nó cũng hạn chế số lượng lọc mà các client cần phải
làm. Trong thực tế, sự chậm trễ mạng để tin rằng bộ nhớ đệm của các client
nhiều hơn điều nó thực sự làm, vì vậy một số bộ lọc có thể được yêu cầu ngay
cả trong KSU nơi server chuẩn bị những thông điệp riêng cho từng client.
Một phần mở rộng của các phương pháp knowledgeable-server sẽ là một
trong đó cho phép server nhìn về phía trước và gửi các bản cập nhật cho client
với tất cả các item đó sẽ hết hạn trước khi nhận được thông báo tiếp theo từ
server. Tương tự như phương pháp có thể đảm bảo rằng client có một bản sao
mới của bất kỳ mục lưu trữ nào nhưng là phức tạp hơn trong đó các client bây
giờ có thể cần phải giữ lại nhiều phiên bản của một mục lưu trữ để đảm bảo
rằng nó có thông tin mới cho toàn bộ khoảng thời gian giữa quá trình phát đi.
Phương pháp này là hấp dẫn vì nó bây giờ ngăn chặn sự cần thiết phải xem xét
dấu thời gian trong các thuật toán bộ nhớ đệm nhưng nó đòi hỏi các giao thức
phức tạp hơn để đảm bảo rằng các bộ nhớ đệm được cập nhật. Chúng ta không
nghiên cứu việc thực hiện thực nghiệm của phương pháp này, nhưng đề cập đến
nó như là một nghiên cứu trong tương lai.
Page 18


Thiết kế thuật toán bộ nhớ đệm riêng để xử lý dữ liệu hết hạn
4.1. Thuật toán tác dụng của thông điệp server
Lưu ý rằng trong CR không có chuyện client nhận được thông tin từ
server vượt quá những gì họ yêu cầu cụ thể và các client hoạt động độc lập. Như
vậy, trường hợp này chỉ đơn giản là lưu trữ nhiều hoạt động độc lập cùng một
lúc, vì vậy các thuật toán của Mục 2 và các quan sát của Phần 3 áp dụng trực
tiếp cùng nhau đối với client. Một khi chúng ta giới thiệu các khái niệm về các

tin nhắn từ server, chúng ta cần phải xác định cụ thể tương tác với server diễn ra
như thế nào, và chúng ta cần phải xem xét lại các thuật toán bộ nhớ đệm của
chúng tôi để xác định cách tương tác với cập nhật server. Như chúng tôi đã đề
cập, một trong ba trường hợp với server bắt đầu gửi tin nhắn ảnh hưởng đến lưu
trữ của client trong cùng một cách chính xác, do đó báo cáo chúng tôi thực hiện
trong phần còn lại áp dụng cho tất cả ba trường hợp. Trong mỗi trường hợp, các
server định kỳ thông báo cho khách hàng về các item có bản dịch đã thay đổi kể
từ thông báo cuối cùng. Chúng tôi đề cập đến thời gian giữa cập nhật thông điệp
như thời gian chu kỳ cập nhật. [14].
Tương tự như vậy với một chu kỳ cập nhật, LRU hai tầng không thể
chiếm ưu thế hơn LRU đơn tầng. Một ví dụ đơn giản về điểm. Xem xét bộ nhớ
đệm với một item hết hạn, gọi nó là x, như vậy x không phải là item đơn tầng
LRU sẽ chọn để bỏ qua ở phần tiếp theo. Do đó, x đã được sử dụng gần đây hơn
một số item ban đầu. Bây giờ giả sử rằng kịch bản sau đây xảy ra: 1) chúng ta
bỏ qua một item từ bộ nhớ đệm để chứa một item mới; 2) các bản cập nhật bộ
nhớ đệm server; 3) item x được yêu cầu. Rõ ràng, trong bộ nhớ đệm hai tầng,
yêu cầu kết quả cho item x trong một bộ nhớ đệm bị bỏ qua nhưng dưới bộ nhớ
đệm đơn tầng thì không. Kết quả như vậy không thể xảy ra mà không cần cập
nhật server. Trực giác nói rằng chiến lược bộ nhớ đệm tương tác với chu kỳ cập
nhật. Các bản cập nhật rất thường xuyên, dữ liệu lưu trữ sẽ hiếm khi hết hạn vì
thế chiến lược bộ nhớ đệm có thể bỏ qua thời gian hết hạn bằng cách sử dụng
phương pháp đơn tầng. Mặt khác, thông tin cập nhật rất thường xuyên có thể có
nhiều lợi ích, vì vậy các biến thể hai tầng sẽ tiếp tục chiếm ưu thế.
Page 19


Thiết kế thuật toán bộ nhớ đệm riêng để xử lý dữ liệu hết hạn
Chúng tôi đã lưu ý rằng, nếu không có thông tin cập nhật định kỳ, chúng
ta có thể không quan tâm tới các item hết hạn trong một chương trình hai tầng
bởi vì tất cả chúng đều sẽ là vô ích một khi hết hạn. Khi có thông tin cập nhật từ

máy chủ, nó sẽ có ý thức để giữ item "tốt nhất" trong mỗi tầng trong dự đoán
của server cập nhật. Vì lý do này, chúng tôi thậm chí áp dụng một thuật toán bộ
nhớ đệm để lựa chọn một item đã hết hạn thu hồi.
Sự xuất hiện của máy chủ cập nhật tăng thêm sự không chắc chắn về khái
niệm hết hạn dự đoán. Nhớ lại rằng trong chiến lược ba tầng, chúng ta phân biệt
giữa các item bộ nhớ đệm không hết hạn để có được item được dự đoán sẽ hết
hạn trước khi sử dụng tiếp theo hoặc không. Kể từ khi client có thể không biết
thời gian chu kỳ cập nhật hoặc thời gian hết hạn trong tương lai của item dữ
liệu, chúng ta sẽ tiếp tục nói rằng một item được dự đoán sẽ hết hiệu lực nếu dự
đoán sử dụng tiếp theo của nó xảy ra sau khi thời gian lưu trữ hết hạn. Tuy
nhiên, điều này là hơi bi quan. Một bản cập nhật chỉ ảnh hưởng đến dự đoán hết
hạn của chúng tôi khi nó xảy ra giữa thời gian hết hạn thực tế của item và dự
đoán sử dụng tiếp theo của nó. Khi điều này xảy ra, chúng tôi dự đoán item hết
hạn nhưng nó sẽ được làm mới bởi các server trước khi dự đoán sử dụng tiếp
theo.
Một câu hỏi mà phát sinh tự nhiên là liệu FF-ET vẫn là thuật toán ẩn tối
ưu khi có server cập nhật. Trong thực tế, câu lệnh còn hiệu lực, nhưng hiện nay
có thông điệp server làm mới dữ liệu lưu trữ. Hiệu ứng này là bản cập nhật
"quan trọng" và một trong đó ngay lập tức đi trước yêu cầu tiếp theo cho item.
Nếu thời gian hết hạn liên quan đến phiên bản của item sau yêu cầu tiếp theo thì
sau đó các item sẽ được làm mới. Nếu nó là trước thời gian yêu cầu thì khi đó
các item đã hết hạn. FF ET ưu tiên bỏ qua các item đã hết hạn theo yêu cầu tiếp
theo của họ. Nếu không item này sẽ bị hết hạn sau đó item có yêu cầu tiếp theo
được chuyển đi nhanh nhất. Như vậy, một mục trong bộ nhớ đệm có thể, trên
thực tế, hết hạn nhiều lần nhưng nó chỉ được coi là hết hạn nếu nó là hết hạn khi
yêu cầu tiếp theo của nó xảy ra.
Page 20


Thiết kế thuật toán bộ nhớ đệm riêng để xử lý dữ liệu hết hạn

4.2. Khối lượng công việc từ thông điệp
Bây giờ chúng ta mô tả các công việc cần thiết cho các chiến lược nhắn
tin client-server mà chúng ta đã mô tả. Trong mọi trường hợp, chúng tôi giả
định vận chuyển đáng tin cậy của tất cả các tin nhắn. Chúng tôi bắt đầu với ba
chiến lược bao gồm các server khởi tạo tin nhắn. Trong khi thiết kế cơ sở dữ
liệu phân tán có thể lưu toàn bộ cơ sở dữ liệu [14], chúng tôi đã chọn để gửi
items thay đổi trong chu kỳ cập nhật. Nhật ký thay đổi này là chính xác những
gì được phát đi cho mỗi client trong chương trình ISB.
Khi server biết item nằm trong bộ nhớ đệm client, server có thể chỉ gửi
thông điệp cập nhật items mà có thay đổi từ bộ nhớ đệm. Chúng tôi gọi đó là
cached change log. Nhật ký thay đổi lưu trữ là sự kết hợp của các item hết hạn
trong bộ nhớ đệm của từng client, cần thiết phải là một tập hợp các thay đổi
đăng nhập cơ sở dữ liệu. Trong chương trình KSB, server phát đi các nhật ký
thay đổi lưu trữ cho tất cả các client. Do đó, nó sẽ gửi thông tin cập nhật cho các
item đã hết hạn được tổ chức bởi bất kỳ client nào cho tất cả client. Để thực
hiện chiến lược này, server duy trì hai trường bổ sung cho mỗi item để xác định
số lượng client có bản sao cũ và mới của mỗi item. Những cái mà bản cũ được
lưu trữ là những cái phải được gửi trong thông báo cập nhật định kỳ.

Page 21


Thiết kế thuật toán bộ nhớ đệm riêng để xử lý dữ liệu hết hạn
thay đổi đăng nhập. Nhật ký thay đổi lưu trữ là sự kết hợp của các mặt hàng hết hạn trong bộ nhớ đệm của từng khách
hàng, mà nhất thiết phải là một tập hợp các thay đổi đăng nhập cơ sở dữ liệu. Trong chương trình KSB, máy chủ chương
trình phát sóng các bản ghi thay đổi lưu trữ cho tất cả các khách hàng. Do đó, nó sẽ gửi thông tin cập nhật cho các hạng mục
đã hết hạn được tổ chức bởi bất kỳ khách hàng cho tất cả khách hàng. Thực hiện chiến lược này, máy chủ duy trì hai trường
bổ sung cho một mặt hàng để xác định số lượng khách hàng có bản sao cũ và mới của mỗi mục. Những người mà bản cũ
được lưu trữ là những người phải được gửi trong bản cập nhật tin nhắn định kỳ.
Một thay thế cho chiến lược quảng bá là cho máy chủ để chuẩn bị thông điệp cập nhật cá nhân cho mỗi khách hàng.

Đây là những gì được thực hiện trong KSU. Trong trường hợp này, máy chủ phải duy trì một danh sách cho từng hạng mục
mà các hồ sơ mà khách hàng có lưu trữ các mục với một chút để cho biết hoặc không phải là bản sao của khách hàng là tươi.
Về lý thuyết, các máy chủ có thể gửi các thông báo cập nhật cho từng cá nhân hoặc thông qua phát đa hướng hoặc điểmđiểm unicast. Khi cấu trúc liên kết mạng là một ngôi sao (như thể hiện trong hình 5) hai là tương đương, vì vậy chúng tôi chỉ
thảo luận về trường hợp unicast trong bài báo này.
Khi một khách hàng nhận được một thông báo cập nhật (hoặc phát sóng hoặc unicast), nó thực hiện một so sánh cặp
với bộ nhớ đệm và cập nhật các nội dung bộ nhớ đệm của nó. Chúng tôi lưu ý rằng bộ lọc này là cần thiết ngay cả trong
trường hợp unicast vì thông báo trục xuất có thể được đồng loạt hoặc nếu không bị trì hoãn.
Bảng 3 tóm tắt các công việc theo yêu cầu của mỗi mô hình trong mỗi chu kỳ cập nhật. Chúng tôi thể hiện kích thước
thông báo về đơn vị thông báo, được định nghĩa là số tiền tối thiểu của không gian cần thiết để chuyển tải một bản dịch duy
nhất, yêu cầu dịch, hoặc thông báo trục xuất
5. Kết quả mô phỏng hệ thống
Trong phần này, chúng tôi cung cấp một nghiên cứu rất sơ bộ của mô hình khách hàng nhắn tin, máy chủ mô tả trong
phần trước. Mục tiêu chính của chúng tôi là quan sát bộ nhớ đệm hiệu suất và khối lượng tin nhắn như tin nhắn cập nhật từ
máy chủ trở nên thường xuyên hơn. Những biến số chính trong mô phỏng của chúng tôi là tần số tin nhắn và các mô hình tin
nhắn. Chúng tôi lưu ý rằng mô hình CR thực sự là một trường hợp hạn chế của ba chiến lược khác đại diện cho khoảng thời
gian dài giữa các tin nhắn. Do đó, chúng tôi không đối xử với nó một cách riêng biệt. Các thông số chúng tôi:
Sử dụng được tóm tắt trong bảng 4. Mô phỏng cơ bản là giống như mô tả trong phần 3 ngoại trừ 100 khách hang, mỗi
hồ sơ theo yêu cầu riêng của họ, chia sẻ máy chủ, và chúng tôi mô phỏng độc lập với các thiết lập này. Vì những lí do được
trích dẫn trong phần 4 và bởi vì chiến lược ba tầng không cải thiện hiệu suất , chúng ta chỉ xem xét một và bộ nhớ đệm 2
tầng.
Mối quan hệ giữa bộ nhớ đệm hiệu suất và tần số cập nhật được minh họa hiệu suất khi dữ liệu không hết hạn và như
vậy cung cấp các trường hợp hạn chế đối với chương trình phát song thường xuyên, di chuyển bên phải, thực hiện như mong
đợi : khi chương trình phát sóng máy chủ là không thường xuyên có rất ít lợi thế hơn ccs yêu cầu của khách hàng và khi cập
nhật được thực hiện thường xuyên cải thiện đáng kể. các dữ liệu thô chỉ ra rằng phát sóng 10 lần trong khoảng thời gian tang
tốc độ truy nhập bộ nhớ đệm hơn 50% so với CR. ở tất cả các tần số cập nhật hai tầng LUR – 2 thuật toán mang lại hiệu suất
tốt nhất nhưng lợi thế của nó trong chiến lược duy nhất tầng làm giảm tại rất thường xuyên và rất thường xuyên cập nhật.
chúng tôi lưu ý rằng các thuật toán thực hiện tương tự với bản cập nhật thường xuyên bởi vì họ tiếp cận hiệu suất tố ưu (theo
quy định của FF-ET) với bộ nhớ đệm kích thước 100 này cũng giống như quan sát của chúng tôi trong phần 3.
Chúng ta xem xét sự cân bằng giữa khối lượng tin nhắn và thực hiện bộ nhớ đệm trong con số 7, nơi tần suất cập nhật
tăng lên di chuyển phải. nhân vật của so sánh là nhất quán trên các thuật toán bộ nhớ đệm khác nhau, vì vậy con số này cho

thấy chỉ có 2 LUR. Các lô con số tổng khối lượng tin nhắn trong 10 mô phỏng quật bộ nhớ đệm tốc độ truy cập cho các
chiến lược thông tin nhắn khác nhau. Bao gồm trong tổng lượng tin nhắn là: các thông báo cập nhật từ máy chủ , tin nhắn bị
đuổi ra khỏi khách hàng với những thông điệp phản ứng máy chủ tạo ra trên một lỗi bộ nhớ đệm. chúng tôi lưu ý rằng một
thông báo trục xuất không xảy ra trên tất cả các lỗi bộ nhớ đệm vì:

Page 22


Thiết kế thuật toán bộ nhớ đệm riêng để xử lý dữ liệu hết hạn
có không ( riêng biệt) là tin nhắn đuổi khi khách hàng yêu cầu một mục cũ trong bộ nhớ cache. Khi có 10 cập nhật mỗi
thời kỳ, chỉ khoảng 4 % yêu cầu kết quả trong một truy cập cũ nhưng với bản cập nhật ít thường xuyên hơn , giá trị này tăng
lên khoảng 20 % .
Không ngạc nhiên, khối lượng tin nhắn tăng lên khi tăng tần số cập nhật (di chuyển bên phải). Bộ nhớ cache tốc độ truy
cập cũng tăng với tần số cập nhật như chúng tôi di chuyển ngay trong con số 7 . Tất cả các chiến lược cải thiện rõ ràng về
hoạt động của CR với chi phí của tin nhắn thêm . Con số này cho thấy chiến lược KSU tạo ra lưu lượng truy cập mạng nhiều
hơn ở mọi cấp độ của bộ nhớ đệm hiệu suất. Chiến lược này có lợi thế là giảm thiểu số lượng lọc dữ liệu mà khách hàng cần
phải làm , nhưng kích thước mà không bị bắt trong biểu đồ này . Với bản cập nhật rất thường xuyên, chiến lược ISB tạo ra
khối lượng tin nhắn ít hơn KSB . Sự khác biệt này là do các tin nhắn đuổi theo khối lượng thực tế KSB. Khối lượng thực tế
là do các tin nhắn quảng bá là ít hơn đáng kể trong KSB hơn tần số tin nhắn SBatall . Một quan sát thú vị là khối lượng tin
nhắn KSB là khá bằng phẳng, do đó sự gia tăng về khối lượng tin nhắn như chương trình phát sóng thường xuyên hơn được
bù đắp bởi giảm trong trục xuất và yêu cầu .
6 . Kết luận
Trong bài báo này , chúng tôi giải quyết vấn đề của khách hàng bộ nhớ đệm trong sự hiện diện của tem thời gian hết
hạn . Chúng tôi - Strate một chiến lược ẩn tối ưu cho bộ nhớ đệm trong sự hiện diện của hết hạn dữ liệu và chúng tôi lưu ý
rằng thuật toán này vẫn tối ưu với những thông điệp cập nhật từ máy chủ. Thông qua so sánh với các thuật toán ẩn tối ưu ,
nghiên cứu mô phỏng của chúng tôi cho thấy rằng một số thuật toán trực tuyến bắt đầu để triển lãm thực hiện thực nghiệm
tối ưu với kích thước bộ nhớ đệm rất nhỏ . Chúng tôi giới thiệu bộ nhớ đệm tầng như một chiến lược đơn giản để cải thiện
hiệu suất khi dữ liệu có thể hết hạn . Chúng tôi thấy rằng hai tầng LRU thể chứng minh chiếm ưu thế LRU và kết quả mô
phỏng của chúng tôi cung cấp bằng chứng thực nghiệm rằng bộ nhớ đệm hai tầng cũng cải thiện LRU -2 mặc dù sự cải thiện
không được đảm bảo về mặt lý thuyết . Cuối cùng, chúng tôi nhận thấy rằng các thông điệp cập nhật từ máy chủ giảm thiểu

những tác động hết hạn dữ liệu.
Dịch vụ điện thoại phụ thuộc thời gian thúc đẩy chúng tôi sử dụng nhãn thời gian hết hạn , tuy nhiên, một số kết quả
có thể được áp dụng trong bối cảnh như DNS và web bộ nhớ đệm . Công việc tương lai của chúng tôi sẽ giải quyết cải tiến
các chiến lược bộ nhớ đệm chúng ta đã mô tả. Chúng tôi sẽ tìm hiểu trước khi tìm nạp ( trước cập nhật ) và các phương pháp
để tối ưu hóa thời gian và nội dung của chương trình phát sóng của máy chủ. Chúng tôi lưu ý rằng khi bản cập nhật được
định kỳ , nó là hấp dẫn để xem xét một bộ nhớ đệm khách hàng nhiều phiên bản với tất cả các phiên bản của một hồ sơ được
áp dụng trong một thời gian . Chúng tôi đã không kiểm tra phương pháp này vì không phải tất cả dịch vụ điện thoại có chu
kỳ này , nhưng nó có thể được quan tâm cho các ứng dụng khác . Ứng dụng điện thoại có chặt chẽ ràng buộc thời gian ,
khách hàng không đồng nhất ( khách hàng ) và thời gian hết hạn dịch vụ phụ thuộc . Những lợi ích thời gian thực của bộ nhớ
đệm phải được đánh giá cẩn thận trong bối cảnh này.

Page 23