潮人地東莞seo博客小編下面跟大家分享關于seo技術緩存服務器的側緩存是怎樣等問題，希望seo專員在做seo優化的過程中有所幫助，內容僅供參考。
?
生活就是這樣，你應該珍惜它。你應該始終是自己的主角，而不是總是在別人的戲劇中扮演配角。
我將從林語堂的《生活就是這樣》中的一句話開始。
出身背景在互聯網快速發展和快速演變的時代，緩存服務無疑已成為系統架構設計中不可或缺的一層。憑借豐富的數據結構、高性能的讀寫和簡單的協議，緩存數據庫可以很好地充當關系數據庫的上層。為了解決節假日或高峰時段車次查詢、搶票等大量數據的訪問請求，長圖早就引入了Redis作為數據庫的上游緩存層，以緩解底層數據庫的讀寫壓力。
seo博客相關推薦閱讀：seo優化推廣：阿亮SEO技術(阿亮seo技術顧問是真的嗎)
REDIS HA架構2014年10月，為了避免單點故障，我們嘗試在生產環境的Redis主從架構中引入Redis Sentinel，以實現Redis服務的故障切換。當Redis Master主機異常停機或Redis Master服務異常崩潰時，原始的Redis Slave會自動升級為Master角色。還原原始Redis Master時，它會自動還原為從屬角色。
seo技術緩存服務器的側緩存是怎樣
由于Redis Sentinel只能切換Redis的服務級別，無法切換IP地址，無法完全滿足現有網絡系統架構的需求，我們嘗試在HA架構中添加一個負載平衡器設備，引用浮動IP。所有應用程序都訪問浮動IP，IP地址切換由負載平衡器設備實現。
Redis Sentinel配置文件
測試總結：
主Redis服務器：redissenst-0-17
從Redis服務器：redissenst-0-18
域名：
redissenst.cache.chhangtu.pvt
重新啟動redissenst-0-17節點。60秒后，重新感知0-18節點成為主節點。用戶訪問redissenst.cache。changtu PVT域名Redis服務恢復正常。兩分鐘后，重新啟動Redis-sent-0-17節點，并自動成為從屬節點;重新啟動redissenst-0-18節點。60秒后，重新感知0-17節點成為主節點。用戶訪問redissenst.cache。changtu pvt域名Redis服務恢復正常。兩分鐘后，Redis-sent-0-18節點重新啟動并自動成為從屬節點。
應用程序要求
通過域名統一訪問緩存應用程序服務。緩存應用服務在訪問Redis域名時具有斷點重新連接功能。
2015年，添加了兩臺Redis Sentinel服務器，以管理平臺上的所有Redis服務器集群。平臺現有的Redis服務將進行改造，逐步升級為Redis HA架構。
CODIS分布式集群隨著長圖網絡業務量的增加和數據量的急劇增加，Redis的單點容量受到服務器內存的限制，Redis主從架構變得無能為力。當業務系統的性能需蓬萊seo優化推廣排名求逐漸增加時，我們傾向于將數據存儲在內存中并在本地持久化，而不是將其寫入數據庫。雖然SSD被用來用磁盤代替內存以獲得更大的容量，但我們希望將Redis改為一種水平可擴展的分布式緩存服務?
在Codis發布之前，業內只有Twemproxy。Twemproxy本身是一個靜態的分布式Redis方案，它需要很高的運維來進行容量擴展和縮減，并且很難實現平穩的容量擴展。Codis的目標是盡可能與Twemproxy兼容，并添加數據遷移功能以實現容量擴展和減少，最終取代Twemprox。本文省略了Twemproxy的介紹。
Codis使用預共享技術對數據進行分區。默認情況下，它分為1024個插槽(0-1023)。對于每個密鑰，插槽ID由以下公式確定：插槽ID=crc32(密鑰)%1024。每個插槽都將具有特定的服務器組ID，以指示哪個服務器組提供插槽數據。
大約在20蘭州移動seo排名16年6月，我們引入了Codis(當時版本是3.0，沒有Redis Sentinel、Codis fe等組件。一年后，升級到3.2。本文主要使用3.0版本作為背景)。首先，我們將介紹基本環境。
系統體系結構
在公司有限的硬件資源下，我們計劃部署6臺服務器的Codis，這些服務器簡單地分為兩層，Codis代理層和Codis服務器層。
Codis代理層使用三個相對較低配置的服務器，并部署ZooKeeper、Codis Proxy、Keepalive、LVS等。三個節點是負載平衡的。Codis服務器層用于三個相對較高配置的服務器，包括SSD和三個Codis組。每個組有一個主設備和一個從設備。它是交叉部署的。每個主設備和從設備分配30G內存。
我們使用jredis編寫測試程序，使用redis基準測試工具模擬壓力測試(請求：1000萬到10億，并發：1000到50000，長度：固定/可變)：
在性能方面，基本可以滿足我們的期望。理想情況下，Codis性能值可以達到50~60K OP/S。每個codis組中的主從實例數據可以實時同步。有關詳細信息，請參閱Codis高可用性群集性能測試報告_20160315。數據一致性：一方面，Codis HA不保證數據不會完全丟失。由于M-S是異步復制，當主節點異常或崩潰，并且從節點切換到主節點時，剛剛未同步的數據將丟失。另一方面，Codis支持的mget/mset命令不能保證單點的原子語義。如果mset指定KEY分布在不同的插槽上，則KEY將分布在不同機器上，從而導致成功或失敗。因此，這是分布式事務的一個難點。在實際場景中，一些人還使用lua腳本來擴展Redis的功能。雖然Codis支持它，但它不能保證腳本操作的數據是否在正確的節點上執行。它僅用作轉發功能。如果不能保證Lua操作的KEY在同一臺機器上，Codis只能將此腳本分配給參數列表中第一個鍵所在的機器執行。不支持命令列表，請參閱https://github.com/CodisLabs/codis/blob/release3.2/doc/unsupported_cmds.mdRedis修改部分(增加若干說明)，請參閱https://github.com/CodisLabs/codis/blob/release3.2/doc/redis_change_zh.md
倔強的青銅
于是我們組織研發同事多次分析討論，提出了緩存服務的接口轉換。經過兩個多月的努力，我們取得了巨大進展，這使我們的Codis項目順利上線。讓我打斷一下。讓我特別感謝我們的同事王輝，他帶領我們完成了公司大部分緩存服務接口轉換工作。
幾個改造思路
1.緩存服務分類。
對于業務緩存服務，不允許數據丟失。在現有的邏輯中，Codis和數據庫將被保留并首先從Codis中讀取。如果無法讀取數據，將從后端數據庫讀取數據。對于車號和伙伴緩存服務，由于數據量大，拉取頻率高的數據只能從Codis中讀取。
2.修改了緩存服務的接口，增加了基本緩存服務層，并將產生的Redis/Codis相關服務包含在基本緩存服務中進行統一管理。
制定一套標準的KEY命名和管理規范，包括數據類型選擇、長度、過期時間等。我們將在后臺管理系統中統一公示，限制新數據的規則，限制所有不規范行為。在基本緩存服務層，一些Codis不支持的命令被重寫，以標準化Redis/Codis的日常操作。熱數據的統計、熱數據的維護以及基本緩存服務層上的二級緩存作為熱數據的快速通道的假設。
3.插槽分配
哈希算法
Codis使用預共享技術對數據進行分區。默認情況下，它分為1024個插槽(0-1023)。對于每個密鑰，插槽ID由以下公式確定：SlotId=crc32(密鑰)%1024。例如，pub_cty_根據算法，ct018的值為997
有趣的整改
在多年的迭代演進過程中，維護團隊數次推動緩存服務架構的升級和優化，緩存服務逐漸得到改善和穩定。記錄了一些“有趣”的糾正措施，供您參考。
熱點數據
緩存熱點數據的統計信息。假設基本緩存服務層上的二級緩存。作為熱點數據的快速通道，它具有動態訪問、訪問速度快、變化少的特點。
根據緩存服務的主鍵和次鍵關系使用索引_{主鍵｝方法用作管理主鍵和子鍵之間關系的SortedSet集合。統計數據的使用頻率用于提取Top100數據作為熱數據。分析這批數據，并根據數據的更改頻率確定內存中這批數據緩存的持續時間。
二級緩存設計
緩存數據列表生成和維護
內存緩存數據的密鑰列表由緩存服務生成和維護。按鍵列表由后臺手動配置(例如，10個按鍵)和根據使用熱量生成的系統(例如，20個按鍵)組成。緩存管理器的jar包只負責使用這些數據。Codis的前20位和后臺手動配置的相關數據是通過預定任務獲得的。在此期間，應保證所獲得數據的有效性。
在本地內存中維護數據
內存緩存的自然統計數據：使用sortedSet集合計算獲取每個棗陽seo快速排名主鍵下所有鍵的次數，并將它們匯總為記分_{主鍵｝方法的集合。使用ZIncrby命令統計相應子鍵的次數，最后匯總每個主鍵以統計Top100的鍵。使用zuonionstore命令匯總信息統計信息，作為內存緩存的基礎。此集合中的數據是從內存中獲得的。
管理類內存緩存：分析和統計項目主進程的關鍵基礎緩存數據并將其保存在內存中，確保相應區域的數據采集和緩存時間，并在離開數據源后最大化CTN的功能。
當發生手動更新時，存儲器中相應的主鍵將被更新
更新發生時，由后臺啟動。緩存服務將標志位放在Codis中。每個客戶端都獲得調度任務中的標志位。如果標志位(cache_memory_update_flag)為Y，則清除內存和密鑰規則表，并在下一個更新周期到來時檢索數據。
總結經過半年多的時間測試和緩存服務接口轉換，2016年9月，國慶節前夕，我們的Codis3.0上線了。在車輛號碼查詢方面，我們有了質的飛躍，特別是在節假日或高峰時段，我們在平滑擴展、數據遷移和高可用性方面表現出了巨大的優勢。
三個代碼_代理節點的平衡：
一年后，從2018年8月到9月，我們將Codis升級到3.2，從之前的6臺服務器升級到7臺。事實上，還有一個額外的Codis web節點，它獨立于Codis fe、Codis dashboard和其他組件。Redis Sentinel、Codis fe等組件的引入為運維人員解決了很多問題。我不會在這里描述它們，但你可以參考那些感興趣的人。
以上是潮人地東莞seo博客跟大家分享關于seo技術緩存服務器的側緩存是怎樣等問題，希望能對大家有所幫助，若有不足之處，請諒解，我們大家可以一起討論關于網站seo優化排名的技巧，一起學習，以上內容僅供參考。
