业务存储改造中的逻辑和清理改造后遗留的问题

本文主要是介绍业务存储改造中的逻辑和清理改造后遗留的问题，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

现象:用户读信时,根据路径的哈希结果,访问四台服务器中一台请求文件,这四台缓存机器已经下线,访问不到再去后端存储访问浪费了时间

前因:每一封信都是一个文件,存储在公司内部的分布式文件系统s3上.因为读取速度太慢和经常的网络访问失败,后来在s3系统之上新增了nginx缓存代理,imap pop web各端都能使用这几台缓存.又增加了阿里云oss存储,与s3存储并行.

1.访问文件的时候,会根据内部的索引服务返回的location进行判断,结果是4,5,6,分别代表只存s3,只存oss,s3和oss双读.代码中对location进行判断,进行读取访问文件.当存在双读的时候,要根据配置优先读取oss或者优先读取s3,读取不到时再去读取另外的存储
2. 在需要读取s3时,在这之上要先访问缓存代理.根据指定的哈希规则,对path部分取哈希值,如果在以下四个范围内就访问指定的IP
‘0~25’=>‘http://xxx.xxx.88’,
‘25~50’=>‘http://xxx.xxx.89’,
‘50~75’=>‘http://xxx.xxx.90’,
‘75~100’=>‘http://xxx.xxx.91’
哈希算法如下:

function BKDRHash($str) {$hash = 0;$seed = 1313;for ($i=0;$i<strlen($str);$i++) {$hash = ((floatval($hash * $seed) & 0x7FFFFFFF) + ord($str[$i])) & 0x7FFFFFFF;}$hash=$hash & 0x7FFFFFFF;return $hash % 100;
}