我目前正在开发一个需要缓存不同资源的应用程序。不同类型的资源具有处理程序,这些处理程序将知道哪些数据与确定相关,我们是否必须重建资源或是否可以从缓存中获取它。为此,处理程序应生成所有相关数据的哈希以进行缓存。根据上下文,数据可以是基元(int、float、...)、字符串、切片、结构和映射。所以几乎所有的东西。用于散列的对象数量也可能有所不同。
为了在处理程序中计算该哈希,我创建了一个带有 type 可变参数的哈希函数interface{}
。
我目前的做法是这样的:
func Hash(objs ...interface{})([]byte) {
// Use MD5 because it's fast and is reasonably enough protected against accidental collisions.
// There is no scenario here where intentional created collisions could do harm.
digester := crypto.MD5.New()
encoder := gob.NewEncoder(digester)
encoder.Encode(objs) // In real life one would handle that error
return digester.Sum(make([]byte, 0))
}
这行得通。但是有一些事情让我对这个实现感到头疼。因为我不确定gob 总是表现出确定性,对于当前版本似乎是这种情况,但正如引用的答案指出的那样,版本之间可能会有变化。根据 gob 的文档,传输结构时将省略默认值(0 表示整数,空字符串,nil,...)。此外,所有 int 值都将作为通用数字传输。所以 unit64 和 int 将是相同的。对于我的用例,我想不出一个实际的问题,但这闻起来像是麻烦的根源。
现在,如果我从头开始编写该函数,我会正确地使用它,用反射遍历结构并创建一个散列树。但我不想那样做。
我很确定我不是第一个有这些要求的人,但是我无法在网络上找到任何经过良好测试的 go 代码来解决这个问题。
附录
另请参阅:https ://crypto.stackexchange.com/questions/10058/how-to-hash-a-list-of-multiple-items
这并不像看起来那么简单。正如 Adrian 指出的那样简单地连接数据是行不通的,因为那时Hash("12", "3")
和Hash("123")
将生成相同的哈希。一种可能的解决方案是在散列之前添加数据长度(和列表元素的数量)或创建散列树,但我想不出一种可靠的方法来处理复杂数据结构中的任何一个,没有编写大量反射代码来处理所有不同的情况(整数、浮点数、字符串、结构、切片等)并遍历整个结构。我想避免这种情况,因为这样做可以监督很多特殊情况,这对我来说似乎没有必要复杂。这就是我尝试使用序列化解决问题的原因,它将解决上述大部分问题。我只是不确定在这种情况下使用 gob 是否有一些缺点,以及是否没有更智能的解决方案。