深刻淺出計算機組成原理學習筆記：第四十九講

1、引子

2012年的時候，我第一次在工做中，遇到一個由於硬件的不可靠性引起的Bug。正是由於這個Bug，讓我開始逐步花不少的時間，去複習回顧整個計算機系統裏面的底層知識。

當時，我正在MediaV帶領一個20多人的團隊，負責公司的廣告數據和機器學習算法。其中有一部分工做，就是用Hadoop集羣處理全部的數據和報表業務。當時咱們的業務增加很快，因此會頻繁地往Hadoop集羣
裏面添置機器。2012年的時候，國內的雲計算平臺還不太成熟，因此咱們都是本身採購硬件，放在託管的數據中裏面。

那個時候，咱們的Hadoop集羣服務器，在從100臺服務器往1000臺服務器時。咱們以爲，像Dell這樣品牌廠商的服務器太貴了，並且可以提供的硬件配置和咱們的指望也有差別。因而，運維的同窗開始和OEM廠
商合做，本身定製服務器，批量採購硬盤、內存。

那個時候，你們都聽過Google早期發展時，爲了下降成本買了不少二手的硬件來下降成本，經過分佈式的放式來保障系統的可靠性的辦法。雖然咱們尚未摳門到去買二手硬件，不過當時，咱們選擇購買了普通的機械硬盤，而不是企業級的、用在數據中心的機械硬盤；採購了普通的內存條，而不是帶ECC糾錯的服務器內存條，想着能省一點兒是一點兒。

2、單必特翻轉：軟件解決不了的硬件錯誤

一、故障現象

突然有一天，咱們最大的、每小時執行一次的數據處理報表應用，完成時間變得比平時晚了很多。一開始，咱們並無太在乎，畢竟當時數據量天天都在增加，慢一點就慢一點了。可是，接着糟糕的

事情開始發生了。

一放面，咱們發現，報表任務有時候在一個小時以內執行不完，接着，偶爾整個報表任務會執行失敗。因而，咱們不得不停下手頭開發的工做，開始排查這個問題。

用過Hadoop的話，你可能知道，做爲一個分佈式的應用，考慮到硬件的故障，Hadoop自己會在特定節點計算出錯的狀況下，重試整個計算過程。以前的報表跑得慢，就是由於有些節點的計算任務失敗過，只是在
重試以後又成功了。進一步分析，咱們發現，程序的錯誤很是奇怪。有些數據計算的結果，好比「34+23」，結果應該是「57」，可是卻變成了一個美圓符號「$」。

前先後後折騰了一週，咱們發現，從日誌上看，一部分出錯的任務都在一個固定的硬件節點上。

另外一方面，咱們發現，問題出如今咱們新的一批本身定製的硬件上架以後。因而，和運維團隊的同事溝通近期的硬件變動，而且翻閱大量Hadoop社區的郵件組列表以後，咱們有了一個大膽的推測。

二、排查分析過程

咱們推測，這個錯誤，來自咱們本身定製的硬件。定製的硬件沒有使用ECC內存，在大量的數據中，內存中出現了 單比特翻轉（Single-Bit Flip）這個傳說中的硬件錯誤。

那這個符號是怎麼來的呢？是因爲內存中的一個整數字符，遇到了一次單比特翻轉轉化而來的。它的ASCII碼二進制表示是0010 0100，因此它徹底可能來自0011 0100遇到一次在第4個比特的單比特翻轉，也就是
從整數「4」變過來的。可是咱們也只能 推測是這個錯誤，而不能確信是這個錯誤。由於單比特翻轉是一個隨機現象，咱們無法穩定復現這個問題。

 

 

ECC內存的全稱是Error-Correcting Code?memory，中⽂名字叫做 糾錯內存。顧名思義，就是在內存裏面出現錯誤的時候，可以本身糾正過來。

三、解決問題

在和運維同窗溝通以後，咱們把全部本身定製的服務器的內存替換成了ECC內存，以後這個問題就消失了。這也使得咱們基本確信，問題的來源就是由於沒有使用ECC內存。咱們全部工程師的開發團機在2012年，也換成了32G內存。是的，換下來的內存沒有別的去處，都安裝到了研發團隊的開發機上。

3、奇偶校驗和校驗位：捕捉錯誤的好辦法

其實，內存裏面的單比特翻轉或者錯誤，並非一個特別罕見的現象。不管是由於內存的製造質量形成的漏電，仍是外部的射線，都有必定的機率，會形成單比特錯誤。而內存層面的數據出錯，軟件工程師並不知
道，並且這個出錯頗有多是隨機的。趕上隨機出現難以重現的錯誤，你們確定受不了。咱們必需要有一個辦法，避免這個問題。

其實，在ECC內存發明以前，工程師們已經開始經過 奇偶校驗的放式，來發現這些錯誤。

一、奇偶校驗和校驗位

奇偶校驗的思路很簡單。咱們把內存裏面的N位比特當成是一組。常見的，好比8位就是一個字節。而後，用額外的一位去記錄，這8個比特里面有奇數個1仍是偶數個1。若是是奇數個1，那額外的一位就記錄爲1；
若是是偶數個1，那額外的一位就記錄成0。那額外的一位，咱們就稱之爲 校驗碼位。

若是在這個字節裏面，咱們不幸發生了單比特翻轉，那麼數據位計算獲得的校驗碼，就和實際校驗位裏面的數據不同。咱們的內存就知道出錯了。

二、校驗位的優勢

除此以外，校驗位有一個很大的優勢，就是計算很是快，每每只須要遍歷一遍須要校驗的數據，經過一個O(N)的時間複雜度的算法，就能把校驗結果計算出來。
校驗碼的思路，在不少地方都會用到。

比方說，咱們下載一些軟件的時候，你會看到，除了下載的包文件，還會有對應的MD5這樣的哈希值或者循環冗餘編碼（CRC）的校驗文件。這樣，當咱們把對應的軟件下載下來以後，咱們能夠計算一下對應軟件的校驗碼，和官方提供的校驗碼去作個比對，看看是否是同樣。

若是不同，你就不能輕易去安裝這個軟件了。由於有可能，這個軟件包是壞的。可是，還有一種更危險的狀況，就是你下載的這個軟件包，多是被人植如了後們的。安裝上了以後，
你的計算機的安全性就沒有保障了。

三、使用奇偶校驗的缺陷

不過，使用奇偶校驗，仍是有兩個比較大的缺陷。

第一個缺陷，就是奇偶校驗只能解決遇到單個位的錯誤，或者說奇數個位的錯誤。若是出現2個位進行了翻轉，那麼這個字節的校驗位計算結果其實沒有變，咱們的校驗位天然也就不能發現這個錯誤。

第二個缺陷，是它只能發現錯誤，可是不能糾正錯誤。因此，即便在內存裏面發現數據錯誤了，咱們也只能停止程序，而不能讓程序繼續正常地運行下去。若是這個只是咱們的我的電腦，作一些可有可無的應用
，這卻是無所謂了。

可是，你想一下，若是你在服務器上進行某個複雜的計算任務，這個計算已經跑了一週乃至一個月了，還有兩三天就跑完了。這個時候，出現內存裏面的錯誤，要再從頭跑起，估計你心裏是崩潰的。

奇偶校驗的缺陷的方案

因此，咱們須要一個比簡單的校驗碼更好的解決方案，一個可以發現更多位的錯誤，而且可以把這些錯誤糾正過來的解決方案，也就是共程師們發明的ECC內存所使用的解決決案。

咱們不只能捕捉到錯誤，還要可以糾正發生的錯誤。這個策略，咱們一般叫做 糾錯碼（Error CorrectingCode）。它還有意個升級版本，叫做 糾刪碼（Erasure?Code），不只可以糾正錯誤，還可以在錯誤不能
糾正的時候，直接把數據刪除。不管是咱們的ECC內存，仍是網絡傳輸，乃至硬盤的RAID，其實都利⽤了糾錯碼和糾刪碼的相關技術。

想要看看咱們怎麼經過算法，怎麼配置硬件，使得咱們不只可以發現單個位的錯誤，還能發現更多位的錯誤，你必定要記得跟上下一講的內容。

4、總結延伸

好了，讓咱們一塊兒來總結一下今天的內容。

我給你介紹了我本身親身經歷的一個硬件錯誤帶來的Bug。因爲沒有采夠ECC內存，致使咱們的數據處理中，出現了大量的單比特數據翻轉的錯誤。這些硬件帶來的錯誤，其實咱們沒有辦法在軟件層面解決。
若是對於硬件以及硬件自己的原理不夠熟悉，恐怕這個問題的解決方案仍是遙遙無期。若是你對計算機組成原理有所瞭解，並可以意識到，在硬件的存儲層有着數據驗證和糾錯的需求，
那你就能在有限的時間內定位到問題所在。

進一步地，我爲你簡單介紹了奇偶校驗，也就是如何經過冗餘的一位數據，發如今硬件層面出現的位錯誤。可是，奇偶校驗以及其餘的校驗碼，只能發現錯誤，沒有辦法糾正錯誤。因此，下一講，咱們一塊兒來看看，怎麼利用糾錯碼這樣的方式，來解決問題。