-
Notifications
You must be signed in to change notification settings - Fork 394
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add backup and restore #121
base: master
Are you sure you want to change the base?
Conversation
cache_test.go
Outdated
iters := 100 | ||
cache := NewCache(1024) | ||
|
||
f, err := os.Open("/tmp/cache_backup.bin") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This test case depends on the TestBackup has run first.
It would be better if we merge them into one test case TestBackupRestore.
And the ExpireAt related logic is not covered in the test.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if it would be better together, can I cover ExpireAt
in the test, assuming that the backup and restore do not take more than 1s
totalExpire := 15
time.Sleep(time.Duration(minTimeExpire+totalExpire) * time.Second)
for i := 0; i < iters; i++ {
key := mrand.Int()
val := strconv.Itoa(i)
val2, err := cache.GetInt(int64(key))
if i < totalExpire {
if err != nil && err != ErrNotFound {
t.Errorf("err: %s", err)
}
continue
}
if err != nil {
t.Errorf("err: %s", err)
}
if string(val2) != val {
t.Errorf("err: %v %q==%q", key, val, val2)
}
}
For persistent file format, we better add file format version in case we change it later, and calculate the checksum of the content. |
If it were a database, yes, but since it is a cache, its data is volatile. |
It's not about durability, it's about correctness. If the on-disk data is corrupted and we loaded it, then we would return a wrong value to the application. |
what do you think of this?
|
If we store crc value at the end of the file, we can write the entry and calculate the crc value at the same time, so we don't need to iterate the cache twice. And crc32c (Castagnoli) is the fastest checksum algorithm, it takes 4 bytes. |
A single crc at the end of the file? I propose that each entry has a checksum, it can be xxhash, crc32... and only use 2 bytes. |
On restore, we will load all the entries at once, so a singe checksum will be sufficient. |
the problem is that it must be read 2 times, first to check the checksum and then to store. |
Then we can clear the cache if the checksum mismatch at the end. |
if there is already data in the cache we will go to a cold cache |
It's hard to prove which way is better, but redis RDB file use a single checksum, let's just follow it. |
What is the time cost of 1 million data? |
Support dump to file and load from file.