前言
一般来说，数据信息在传输过程中有时会受到外界有意或无意的干扰行为，出现数据的篡改和破坏现象，造成数据接收端的不一致行为。于是乎，在信息领域有了数据校验的概念，今天本文主要来简单聊聊其中的经典使用算法CRC（循环冗余校验）以及其在Ozone中的应用实践。
CRC和Checksum的关系
往往我们在谈论CRC的时候，马上会联想到Checksum这个词，二者是等同的意思吗？实则还是有区别的。
首先我们要区分一个概念上的差别，CRC是一种算法，而Checksum我们指的是一组信息，官方的称呼叫做“总和校验码”。而CRC是其中一种计算校验和信息的算法。换句话说，还有其它算法也可以计算出Checksum信息的（比如MD5算法），只是说CRC太经典以至于让我们误以为CRC和Checksum是等号的关系了。
但是不管说用什么方法，我们用生成的Checksum信息的目的是相同的：用于错误检测，以此保证数据在传输过程中的一致性。
CRC算法被广泛地使用在通信和存储信息领域，得益于以下三点：
- 较为简单地实现于二进制的硬件环境下
- 比较容易去数学分析
- 错误检测的实用性高
CRC的算法原理是使用多项式的除法来做校验和结果的生成，具体涉及的数学理论这里不进行详细介绍了。
CRC的实践应用
在CRC的实际应用场景中，它的应用原理如下：
- 读取一段待传输数据D1，用CRC算法进行此段数据的计算，将此值作为此段数据的Checksum结果。
- 将1)步骤得到的Checksum信息追加在数据D1段的尾部，然后继续重复1)步骤。
基于这种情况下，在接收端获取数据时采用的检测办法如下：
- 接收一段数据包R1，解析得到其数据信息R1和校验和信息CK1。
- 将R1数据进行CRC算法计算校验和信息CK1’
- 比较CK1’和CK1是否一致，如果一致说明数据是完整的，继续下一段的接收处理，否则说明数据已被破坏。
CRC在Ozone中的应用
这里笔者要提一提CRC在Ozone（对象存储）中的另外一种用法，和往常的做法略有不同。
也许是为了保证原始数据格式的兼容性，社区在实现的时候，将Checksum信息保存到了文件的元数据信息里。也就是说，一个文件的metadata里会存在一个或多个Checksum信息组，如下图（图右）所示：
上图左边是传统的使用模式，右图为Ozone的CRC使用模式。因为Ozone是一套存储系统，所以它的验证方式如下：
- 写入文件数据时，按照每个片段数据大小计算其Checksum，并保存到文件metadata信息里。
- 当客户端读文件信息时，重新计算Checksum与原始的做比较即可。
总体来说，和传统的比较方式类似，有关CRC算法更多的资料介绍可阅读文章末尾的wiki链接。