鍵行為差異指南：字符串邊界、過期時間與 Lua 腳本)
Dragonfly 與 Redis 的關(guān)鍵行為差異指南字符串邊界、過期時間與 Lua 腳本【免費下載鏈接】dragonflyA modern replacement for Redis and Memcached項目地址: https://gitcode.com/GitHub_Trending/dr/dragonfly本文基于 Dragonfly 官方文檔 docs/differences.md系統(tǒng)梳理 Dragonfly 與 Redis 在字符串長度與索引、過期TTL/EXPIRE語義、以及 Lua 腳本運行時這三個維度的行為差異。Dragonfly 是一個定位為 A modern replacement for Redis and Memcached 的內(nèi)存數(shù)據(jù)庫它在絕大多數(shù)命令上保持與 Redis 協(xié)議兼容但在少數(shù)邊界語義上做了有意的取舍與擴展。讀完本文你將清楚了解哪些用法在遷移到 Dragonfly 時需要特別留意、哪些用法反而是 Dragonfly 相對 Redis 的增強能力。字符串長度與索引范圍差異字符串大小上限256MBDragonfly 將單個字符串String值的大小限制為256MB。這意味著所有以字符串為載體的命令SET、SETRANGE、APPEND、GETRANGE等在處理超過 256MB 的數(shù)據(jù)時都會受到該上限約束。該限制在源碼與測試中有多處印證src/server/string_family_test.cc 中的測試注釋明確寫道 we support only 256MB string并注釋掉了SETRANGE到268435456即 2^28 字節(jié) 256MB偏移量的用例src/server/bitops_family_test.cc 中針對位操作的測試也指出 2200000000 bits 275MB, above the 256MB cap確認對超出上限的操作會按 256MB 封頂處理從底層存儲看src/server/tiering/external_alloc.h 與 src/server/tiering/external_alloc.cc 表明外置存儲按256MB 一個 segment組織字符串上限與段粒度保持對齊。遷移建議如果你的應用依賴超過 256MB 的單個字符串值例如超大緩存對象直接塞進一個 key在 Dragonfly 上需要改為分片存儲或改用其他數(shù)據(jù)結(jié)構(gòu)承載。GETRANGE / SETRANGE 的索引類型GETRANGE、SETRANGE等命令的索引參數(shù)必須是有符號 32 位整數(shù)取值范圍為[-2147483647, 2147483648]。超出該范圍的索引會被拒絕或按邊界處理而不是像 Redis 那樣接受更寬的整數(shù)。src/server/string_family_test.cc 中對GETRANGE/SETRANGE的邊界行為做了充分覆蓋例如負索引從字符串尾部計數(shù)、start end時返回空串、SETRANGE偏移超過當前長度時以零字節(jié)填充等。SORT 不區(qū)分 localeSORT命令在排序字符串時不考慮任何 locale區(qū)域設置即按固定的字節(jié)序比較而不是按語言/區(qū)域的字典序排序。這與 Redis 的行為一致Redis 同樣不按 locale 排序文檔在此特別列出是為了提醒依賴 locale 感知排序的應用Dragonfly 不提供 locale-aware 的SORT語義如果需要語言化排序請在客戶端自行處理。過期Expire語義差異EXPIRE 系列命令的 NX/GT/LT 組合有意的擴展Dragonfly 的EXPIRE、PEXPIRE、EXPIREAT、PEXPIREAT允許NX 與 GT 或 LT 同時出現(xiàn)而 Redis 會拒絕這些組合視為不兼容。具體語義如下當 key沒有過期時間時NX 生效即按 NX 語義設置過期時間當 key已有過期時間時忽略 NX僅由GT 或 LT單獨決定——GT 表示僅當新過期時間晚于當前過期時間才設置LT 表示僅當新過期時間早于當前過期時間才設置。該擴展并非文檔的孤證在實現(xiàn)中有明確的注釋標注。查看 src/server/generic_family.cc 的ParseExpireArgs// NX with GT/LT is allowed as a deliberate extension, see docs/differences.md. if ((args.flags ExpireFlags::EXPIRE_NX) (args.flags ExpireFlags::EXPIRE_XX)) parser-ReportCustom(NX and XX, GT or LT options at the same time are not compatible); if ((args.flags ExpireFlags::EXPIRE_GT) (args.flags ExpireFlags::EXPIRE_LT)) parser-ReportCustom(GT and LT options at the same time are not compatible);可以看到NX 與 XX 組合、GT 與 LT 組合仍然是被拒絕的只有 NX GT 或 NX LT 這種組合被放行且源碼注釋直接指向本文檔docs/differences.md作為設計依據(jù)。在底層執(zhí)行層面src/server/db_slice.cc 的UpdateExpire也對這一擴展做了逐字對應的注釋與實現(xiàn)// Every given flag must hold. Exception: NX with GT/LT (deliberate extension) sets the // expiry when there is none, otherwise GT/LT alone decides. int32_t opts params.expire_options; if ((opts ExpireFlags::EXPIRE_NX) (opts (ExpireFlags::EXPIRE_GT | ExpireFlags::EXPIRE_LT))) { opts has_expire ? opts ~ExpireFlags::EXPIRE_NX : int32_t{ExpireFlags::EXPIRE_ALWAYS}; }即當 NX 與 GT/LT 并存時若 key 已有過期時間則剝離 NX 位由 GT/LT 決定若 key 無過期時間則退化為無條件設置。使用示例EXPIRE key 100 NX GT表示僅當 key 不存在過期時間時設置為 100 秒或者若已有過期時間僅當 100 秒晚于當前過期時間時更新。這類組合在 Redis 上會直接報錯在 Dragonfly 上則可正常執(zhí)行遷移時需要注意這一增強行為。過期時間上限約 8 年毫秒精度命令靜默降精度Dragonfly 的過期時間被限制在8 年以內(nèi)。具體地源碼中定義了src/server/common.hconstexpr int64_t kMaxExpireDeadlineSec (1u 28) - 1; // 8.5 years constexpr int64_t kMaxExpireDeadlineMs kMaxExpireDeadlineSec * 1000;即相對過期時間的上限為 2^28 - 1 秒約 8.5 年。對于PEXPIRE、PSETEX 這類毫秒精度命令當設置的過期時間大于 2^28 毫秒約 3 天多不2^28 ms ≈ 3.1 天需按秒級上限處理時會被靜默四舍五入到最近的秒引入的精度損失小于 0.001%。實現(xiàn)上src/server/db_slice.cc 的ExpireParams構(gòu)造函數(shù)處理了靜默封頂邏輯當cap為真且毫秒值超過kMaxExpireDeadlineMs時直接鉗制到該上限該上限是整秒的整數(shù)倍因此毫秒精度在此被丟棄if (cap now_ms 0 ms_value kMaxExpireDeadlineMs) { ms_value kMaxExpireDeadlineMs; }而絕對時間戳EXPIREAT/PEXPIREAT與相對 TTL 的行為有所不同測試 src/server/generic_family_test.cc 驗證了兩類邊界巨大的絕對時間戳會溢出kMaxExpireDeadlineMs上限命令返回OUT_OF_RANGE錯誤巨大的相對 TTL會被靜默封頂?shù)絢MaxExpireDeadlineSec約 8.5 年隨后TTL/PTTL返回該封頂值。// Huge absolute timestamps overflow the kMaxExpireDeadlineMs cap and surface OUT_OF_RANGE. // Huge relative TTLs are silently capped to kMaxExpireDeadlineSec (~8.5 years). EXPECT_EQ(CheckedInt({ttl, key}), kMaxExpireDeadlineSec); EXPECT_THAT(Run({pexpire, key, absl::StrCat(int64_t{kMaxExpireDeadlineMs} * 10)}), IntArg(1)); EXPECT_EQ(CheckedInt({pttl, key}), kMaxExpireDeadlineMs);遷移建議如果你在 Redis 上設置了遠超 8 年的過期時間例如使用絕對時間戳做永不過期的替代方案在 Dragonfly 上要么改用PERSIST要么接受 8.5 年上限同時注意絕對時間戳形式在超限時會報錯而相對 TTL 是靜默封頂。Lua 腳本運行時差異Dragonfly 內(nèi)置的 Lua 解釋器版本為Lua 5.4.42022 年發(fā)布而 Redis 長期使用的 Lua 5.1 已經(jīng)較為陳舊。這一版本升級帶來最直接的差異是Dragonfly 的 Lua 腳本支持 Lua 5.4 的整數(shù)類型integer包括math.maxinteger、math.mininteger、整數(shù)除法//、位運算等 5.3 特性這也是 Redis 社區(qū)長期討論的 lua integers 議題所倡導的方向。在實現(xiàn)層面src/core/interpreter.cc 的錯誤提示直接引用了 Lua 5.4 官方手冊的整數(shù)語義章節(jié)同時 src/core/interpreter.cc 展示了浮點轉(zhuǎn)整數(shù)時對lua_Integer邊界INT64_MIN/INT64_MAX的顯式檢查if (abs(fractpart) kConvertEps intpart double(std::numeric_limitslua_Integer::max()) intpart std::numeric_limitslua_Integer::min()) lua_pushinteger(lua_, static_castlua_Integer(d));此外interpreter.cc還通過luaopen_base、luaopen_table等標準庫加載方式初始化運行時src/core/interpreter.cc并在腳本執(zhí)行中對math.randomstring等擴展函數(shù)設置了明確的資源上限如單次隨機字符串 16MiB、單次最多 32k 個隨機串見 src/core/interpreter.cc防止腳本過度消耗內(nèi)存。遷移建議如果遷移過來的 Redis Lua 腳本依賴 5.1 的老式行為例如math.random的種子行為、浮點/整數(shù)隱式轉(zhuǎn)換的差異建議先用 Dragonfly 的EVAL做一遍腳本回歸測試反之如果你此前受困于 Lua 5.1 缺少 64 位整數(shù)Dragonfly 的 5.4.4 會帶來更自然的整數(shù)處理能力?？偨Y(jié)遷移前需要對照的三張差異清單維度Redis 行為Dragonfly 行為遷移關(guān)注點字符串大小上限 512MB上限256MB超大字符串值需重新設計GETRANGE/SETRANGE 索引64 位有符號整數(shù)有符號 32 位[-2147483647, 2147483648]超大偏移量用法需調(diào)整SORT 排序無 locale 感知無 locale 感知文檔明確列出語言化排序需在客戶端實現(xiàn)EXPIRE NXGT/LT拒絕該組合允許無過期時 NX 生效有過期時 GT/LT 決定屬于增強特性注意行為差異NXXX、GTLT拒絕同樣拒絕與 Redis 保持一致過期時間上限無明確 8 年限制約8 年2^28-1 秒相對 TTL 靜默封頂絕對時間戳超限報OUT_OF_RANGE毫秒精度命令超 2^28ms 靜默降精度0.001%超長過期時間需改用PERSISTLua 運行時Lua 5.1Lua 5.4.4支持整數(shù)類型math.maxinteger等5.1 老腳本需回歸測試可受益于整數(shù)能力Dragonfly 與 Redis 的協(xié)議兼容度很高真正的差異集中在上述少數(shù)邊界語義上。無論是從 Redis 遷移到 Dragonfly還是雙寫/混合部署建議將本文的差異點整理進自己的兼容性測試矩陣并參照 docs/differences.md 與 tests/dragonfly 下的測試用例做針對性驗證?！久赓M下載鏈接】dragonflyA modern replacement for Redis and Memcached項目地址: https://gitcode.com/GitHub_Trending/dr/dragonfly創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考 Dragonfly 與 Redis 的關(guān)鍵行為差異指南：字符串邊界、過期時間與 Lua 腳本
Dragonfly 與 Redis 的關(guān)鍵行為差異指南字符串邊界、過期時間與 Lua 腳本【免費下載鏈接】dragonflyA modern replacement for Redis and Memcached項目地址: https://gitcode.com/GitHub_Trending/dr/dragonfly本文基于 Dragonfly 官方文檔 docs/differences.md系統(tǒng)梳理 Dragonfly 與 Redis 在字符串長度與索引、過期TTL/EXPIRE語義、以及 Lua 腳本運行時這三個維度的行為差異。Dragonfly 是一個定位為 A modern replacement for Redis and Memcached 的內(nèi)存數(shù)據(jù)庫它在絕大多數(shù)命令上保持與 Redis 協(xié)議兼容但在少數(shù)邊界語義上做了有意的取舍與擴展。讀完本文你將清楚了解哪些用法在遷移到 Dragonfly 時需要特別留意、哪些用法反而是 Dragonfly 相對 Redis 的增強能力。字符串長度與索引范圍差異字符串大小上限256MBDragonfly 將單個字符串String值的大小限制為256MB。這意味著所有以字符串為載體的命令SET、SETRANGE、APPEND、GETRANGE等在處理超過 256MB 的數(shù)據(jù)時都會受到該上限約束。該限制在源碼與測試中有多處印證src/server/string_family_test.cc 中的測試注釋明確寫道 we support only 256MB string并注釋掉了SETRANGE到268435456即 2^28 字節(jié) 256MB偏移量的用例src/server/bitops_family_test.cc 中針對位操作的測試也指出 2200000000 bits 275MB, above the 256MB cap確認對超出上限的操作會按 256MB 封頂處理從底層存儲看src/server/tiering/external_alloc.h 與 src/server/tiering/external_alloc.cc 表明外置存儲按256MB 一個 segment組織字符串上限與段粒度保持對齊。遷移建議如果你的應用依賴超過 256MB 的單個字符串值例如超大緩存對象直接塞進一個 key在 Dragonfly 上需要改為分片存儲或改用其他數(shù)據(jù)結(jié)構(gòu)承載。GETRANGE / SETRANGE 的索引類型GETRANGE、SETRANGE等命令的索引參數(shù)必須是有符號 32 位整數(shù)取值范圍為[-2147483647, 2147483648]。超出該范圍的索引會被拒絕或按邊界處理而不是像 Redis 那樣接受更寬的整數(shù)。src/server/string_family_test.cc 中對GETRANGE/SETRANGE的邊界行為做了充分覆蓋例如負索引從字符串尾部計數(shù)、start end時返回空串、SETRANGE偏移超過當前長度時以零字節(jié)填充等。SORT 不區(qū)分 localeSORT命令在排序字符串時不考慮任何 locale區(qū)域設置即按固定的字節(jié)序比較而不是按語言/區(qū)域的字典序排序。這與 Redis 的行為一致Redis 同樣不按 locale 排序文檔在此特別列出是為了提醒依賴 locale 感知排序的應用Dragonfly 不提供 locale-aware 的SORT語義如果需要語言化排序請在客戶端自行處理。過期Expire語義差異EXPIRE 系列命令的 NX/GT/LT 組合有意的擴展Dragonfly 的EXPIRE、PEXPIRE、EXPIREAT、PEXPIREAT允許NX 與 GT 或 LT 同時出現(xiàn)而 Redis 會拒絕這些組合視為不兼容。具體語義如下當 key沒有過期時間時NX 生效即按 NX 語義設置過期時間當 key已有過期時間時忽略 NX僅由GT 或 LT單獨決定——GT 表示僅當新過期時間晚于當前過期時間才設置LT 表示僅當新過期時間早于當前過期時間才設置。該擴展并非文檔的孤證在實現(xiàn)中有明確的注釋標注。查看 src/server/generic_family.cc 的ParseExpireArgs// NX with GT/LT is allowed as a deliberate extension, see docs/differences.md. if ((args.flags ExpireFlags::EXPIRE_NX) (args.flags ExpireFlags::EXPIRE_XX)) parser-ReportCustom(NX and XX, GT or LT options at the same time are not compatible); if ((args.flags ExpireFlags::EXPIRE_GT) (args.flags ExpireFlags::EXPIRE_LT)) parser-ReportCustom(GT and LT options at the same time are not compatible);可以看到NX 與 XX 組合、GT 與 LT 組合仍然是被拒絕的只有 NX GT 或 NX LT 這種組合被放行且源碼注釋直接指向本文檔docs/differences.md作為設計依據(jù)。在底層執(zhí)行層面src/server/db_slice.cc 的UpdateExpire也對這一擴展做了逐字對應的注釋與實現(xiàn)// Every given flag must hold. Exception: NX with GT/LT (deliberate extension) sets the // expiry when there is none, otherwise GT/LT alone decides. int32_t opts params.expire_options; if ((opts ExpireFlags::EXPIRE_NX) (opts (ExpireFlags::EXPIRE_GT | ExpireFlags::EXPIRE_LT))) { opts has_expire ? opts ~ExpireFlags::EXPIRE_NX : int32_t{ExpireFlags::EXPIRE_ALWAYS}; }即當 NX 與 GT/LT 并存時若 key 已有過期時間則剝離 NX 位由 GT/LT 決定若 key 無過期時間則退化為無條件設置。使用示例EXPIRE key 100 NX GT表示僅當 key 不存在過期時間時設置為 100 秒或者若已有過期時間僅當 100 秒晚于當前過期時間時更新。這類組合在 Redis 上會直接報錯在 Dragonfly 上則可正常執(zhí)行遷移時需要注意這一增強行為。過期時間上限約 8 年毫秒精度命令靜默降精度Dragonfly 的過期時間被限制在8 年以內(nèi)。具體地源碼中定義了src/server/common.hconstexpr int64_t kMaxExpireDeadlineSec (1u 28) - 1; // 8.5 years constexpr int64_t kMaxExpireDeadlineMs kMaxExpireDeadlineSec * 1000;即相對過期時間的上限為 2^28 - 1 秒約 8.5 年。對于PEXPIRE、PSETEX 這類毫秒精度命令當設置的過期時間大于 2^28 毫秒約 3 天多不2^28 ms ≈ 3.1 天需按秒級上限處理時會被靜默四舍五入到最近的秒引入的精度損失小于 0.001%。實現(xiàn)上src/server/db_slice.cc 的ExpireParams構(gòu)造函數(shù)處理了靜默封頂邏輯當cap為真且毫秒值超過kMaxExpireDeadlineMs時直接鉗制到該上限該上限是整秒的整數(shù)倍因此毫秒精度在此被丟棄if (cap now_ms 0 ms_value kMaxExpireDeadlineMs) { ms_value kMaxExpireDeadlineMs; }而絕對時間戳EXPIREAT/PEXPIREAT與相對 TTL 的行為有所不同測試 src/server/generic_family_test.cc 驗證了兩類邊界巨大的絕對時間戳會溢出kMaxExpireDeadlineMs上限命令返回OUT_OF_RANGE錯誤巨大的相對 TTL會被靜默封頂?shù)絢MaxExpireDeadlineSec約 8.5 年隨后TTL/PTTL返回該封頂值。// Huge absolute timestamps overflow the kMaxExpireDeadlineMs cap and surface OUT_OF_RANGE. // Huge relative TTLs are silently capped to kMaxExpireDeadlineSec (~8.5 years). EXPECT_EQ(CheckedInt({ttl, key}), kMaxExpireDeadlineSec); EXPECT_THAT(Run({pexpire, key, absl::StrCat(int64_t{kMaxExpireDeadlineMs} * 10)}), IntArg(1)); EXPECT_EQ(CheckedInt({pttl, key}), kMaxExpireDeadlineMs);遷移建議如果你在 Redis 上設置了遠超 8 年的過期時間例如使用絕對時間戳做永不過期的替代方案在 Dragonfly 上要么改用PERSIST要么接受 8.5 年上限同時注意絕對時間戳形式在超限時會報錯而相對 TTL 是靜默封頂。Lua 腳本運行時差異Dragonfly 內(nèi)置的 Lua 解釋器版本為Lua 5.4.42022 年發(fā)布而 Redis 長期使用的 Lua 5.1 已經(jīng)較為陳舊。這一版本升級帶來最直接的差異是Dragonfly 的 Lua 腳本支持 Lua 5.4 的整數(shù)類型integer包括math.maxinteger、math.mininteger、整數(shù)除法//、位運算等 5.3 特性這也是 Redis 社區(qū)長期討論的 lua integers 議題所倡導的方向。在實現(xiàn)層面src/core/interpreter.cc 的錯誤提示直接引用了 Lua 5.4 官方手冊的整數(shù)語義章節(jié)同時 src/core/interpreter.cc 展示了浮點轉(zhuǎn)整數(shù)時對lua_Integer邊界INT64_MIN/INT64_MAX的顯式檢查if (abs(fractpart) kConvertEps intpart double(std::numeric_limitslua_Integer::max()) intpart std::numeric_limitslua_Integer::min()) lua_pushinteger(lua_, static_castlua_Integer(d));此外interpreter.cc還通過luaopen_base、luaopen_table等標準庫加載方式初始化運行時src/core/interpreter.cc并在腳本執(zhí)行中對math.randomstring等擴展函數(shù)設置了明確的資源上限如單次隨機字符串 16MiB、單次最多 32k 個隨機串見 src/core/interpreter.cc防止腳本過度消耗內(nèi)存。遷移建議如果遷移過來的 Redis Lua 腳本依賴 5.1 的老式行為例如math.random的種子行為、浮點/整數(shù)隱式轉(zhuǎn)換的差異建議先用 Dragonfly 的EVAL做一遍腳本回歸測試反之如果你此前受困于 Lua 5.1 缺少 64 位整數(shù)Dragonfly 的 5.4.4 會帶來更自然的整數(shù)處理能力?？偨Y(jié)遷移前需要對照的三張差異清單維度Redis 行為Dragonfly 行為遷移關(guān)注點字符串大小上限 512MB上限256MB超大字符串值需重新設計GETRANGE/SETRANGE 索引64 位有符號整數(shù)有符號 32 位[-2147483647, 2147483648]超大偏移量用法需調(diào)整SORT 排序無 locale 感知無 locale 感知文檔明確列出語言化排序需在客戶端實現(xiàn)EXPIRE NXGT/LT拒絕該組合允許無過期時 NX 生效有過期時 GT/LT 決定屬于增強特性注意行為差異NXXX、GTLT拒絕同樣拒絕與 Redis 保持一致過期時間上限無明確 8 年限制約8 年2^28-1 秒相對 TTL 靜默封頂絕對時間戳超限報OUT_OF_RANGE毫秒精度命令超 2^28ms 靜默降精度0.001%超長過期時間需改用PERSISTLua 運行時Lua 5.1Lua 5.4.4支持整數(shù)類型math.maxinteger等5.1 老腳本需回歸測試可受益于整數(shù)能力Dragonfly 與 Redis 的協(xié)議兼容度很高真正的差異集中在上述少數(shù)邊界語義上。無論是從 Redis 遷移到 Dragonfly還是雙寫/混合部署建議將本文的差異點整理進自己的兼容性測試矩陣并參照 docs/differences.md 與 tests/dragonfly 下的測試用例做針對性驗證?！久赓M下載鏈接】dragonflyA modern replacement for Redis and Memcached項目地址: https://gitcode.com/GitHub_Trending/dr/dragonfly創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考