因專案｛acs接入服務｝利用netty框架建立協議獲取客戶端資料，需要redis對這些大量資料做快取。專案進展一個多月，還並未發現redis的使用存在異常。至2018年年初，在對傳入資料做一些穩定性測試的時候，頻繁發現數據存在間歇性讀取異常（儀器的小時資料），一開始以為編寫的程式碼可能存在邏輯性問題，通過逐步排查發現系統在獲取redis的鍵Hour_Number引數｛記錄appweb定時器擷取的資料長度，acs資料更新時會重置長度並刪除該長度舊資料，以此實現【擷取】功能｝時存在異常，(但專案存在一個業務場景，在netty的一個連線｛表示一個執行緒｝中，在小時整點時會幾乎同時觸發實時、分鐘、小時資料至redis的儲存｛存資料｝，同時關聯的appweb｛取資料｝卻也幾乎同時執行｛兩者在日誌中列印時間相差不過零點幾毫秒｝，但兩者執行的方法又比較長，因此一直覺得這裡面對redis的操作可能存在問題，由於部分程式碼被組建化無法除錯，因此列印日誌希望重現問題找出原因｛日誌也存在列印不全的情況，在後來直接看命令列打印發現這個問題｝）。週五重新部署了一遍。

   由於心有不甘，週六吃過中飯就又來公司看專案執行情況。這一看不要緊，發現又有資料丟失了，登入阿里伺服器看專案執行情況，app｛竟然報空指標，一看程式碼redis資料沒拿到｝，開啟redis，鍵值app部分全沒了｛問了下同事發現並非人為｝。此時還沒意識到redis的db0有兩個鍵｛以為是其他同事加進去的｝，在網上查詢redis大量資料還以為是redis的鍵過期回收策略問題｛LRU淘汰策略點選開啟連結｝。以下為DB0的兩個鍵。

毫無頭緒，就將db0刪了｛單純覺得不正常，這其實不符合逐點排除問題原則，但此時回想刪了反倒幫我找出問題了｝，重啟了一遍acs服務但未啟動app，包括redis。意外發現鍵值又回來了，說明redis的持久化RDB備份檔案並未被修改。問了下堂哥｛做redis中介軟體的，大神級人物｝，幫我排查問題，但都只能窄化問題範圍，還未找到根源｛怪我描述重點不對！｝。再一次部署。

     至週六晚上7點到週末晚上12點，資料都執行正常。週一上班發現問題重現，同時刪除的db0鍵又出現了，這讓我不得不重視db0這兩個鍵，看內容查了下ip地址，義大利IP.諸多的不正常意見如重磅炸彈的ip地址，讓我不得不覺得，redis被攻擊了。檢索了下redis攻擊資料，與情況相符｛redis沒有配置密碼【命令方式配置密碼聽說是臨時的，斷電失效】，未授權攻擊｝。redis機制導致暴露外網任意訪問。還好伺服器是window的並未造成更嚴重影響｛該木馬原來是針對linux的，這又不得不感嘆，落伍原來也有好處！！！｝。

     網上的相關資料很多，就不一一描述了，根據實際情況｛目前幾個服務都在一個阿里雲伺服器上｝，有如下幾個方案：

1：設定繫結ip

修改redis.windows-service.conf檔案｛redis服務端配置檔案｝，bind 127.0.0.1 （多個ip繫結的意思是redis本機，redis所在區域網ip並非任意ip得｛很顯然阿里伺服器跟我公司不在一個區域網，只能寫127.0.0.1，這樣導致遠端客戶端是連線不上的，只能本機上連｝），最後｛最重要一步｝，讓redis帶配置啟動，也就是配置檔案改為redis.windows-service.conf。

     bat下完整命令為：

注：之前這個命令一直執行失敗，後來發現是redis版本問題，換了一份網上的版本點選開啟連結就行了。執行成功會生成log日誌的。

總體來說這個方法是最安全的，但卻是難以擴充套件的｛服務不在同一個伺服器上時怎麼辦呢｝，而且觀察資料也很不方便。

2：修改埠，授權訪問

修改redis.windows-service.conf中port埠號如"6479",修改requirepass引數密碼越長越好"UIHDH74593IOZHDSF$^*&(%$#$SDFF"｛另外命令方式配置密碼斷電會丟失，所以選則這種｝。

在redis.windows-service.conf中配置

將redis.windows-service.conf檔案設定只讀許可權。

以低許可權啟動redis：

如上步操作出現“此任務要求指定的使用者帳戶以批處理作業許可權登入”，則需要登入cmd-》gpedit.msc計算機配置，為賬戶新增批處理許可權。點選開啟連結

另外別忘了redis資料夾給這個使用者訪問許可權。

開啟防火牆｛這一步沒試過，禁止某ip訪問｝。

待結果出來後期會補更！！！！