上周我们将Cravatar完全完善好并上线开启公测。
计划中公测大约持续1周，之后会集成到WP-China-Yes推送，再经过一周后运行稳定的话就会挨个联系开发者们在自己的产品中集成。
Cravatar最让我感到炫酷的功能是支持在用户未设置Cravatar头像和Gravatar头像的情况下自动为其返回QQ头像，当然这只对使用QQ数字邮箱的用户有效。
经过对litepress.cn注册用户的统计，QQ数字邮箱的使用比例大约未30%，能为如此比例的用户显示准确的头像，我个人认为意义还是蛮大的。
但这一功能的实现却并不容易。
可能很多朋友不理解：不就是从QQ邮箱里提取QQ号就OK了吗，这有啥难的。
话是这样讲没错了，但是如果我们再向前一步思考：QQ邮箱从何而来？是不是就懵掉了。因为按Gravatar的API规范，其传递的是邮箱的哈希值，而不是邮箱本身。哈希值是不可逆运算的，所以我们其实获取不到用户的邮箱地址。
为了能实现这个需求，我们考虑了三套方案：
- 实现一套新的API协议，使用可解密的非对称加密算法对邮箱地址加密
- 在插件段实现对QQ头像的对接
- 穷举所有QQ邮箱的哈希值，并存储为彩虹表，这样就可以通过邮箱哈希查询到QQ号了
针对以上三种方案，方案一破坏了对Gravatar API的兼容性，基本可以Pass；方案二会影响用户网站的速度（因为要在后端请求是否存在C头像和G头像）；只有方案三能完美实现这个需求，但也是技术难度最大的一种。
老实说，其实方案三的原理也很简单，但耐不住数据量大呀！就好像实现一个商城程序很简单，但是实现一个能抗住双十一的淘宝可不容易。穷举所有QQ邮箱后的数据条目达到了50亿条，体积达到了600G，如何将其导入数据库以及如何有效查询是我们面临的主要问题。
这里对技术方案做一下简单记录：
1、数据表设计
将50亿数据全存入一张表显然是不切实际的，实际测试来看单表数据达到1000万后就直接卡死了（我们使用的是普通的机械盘），所以这里将数据拆分为5000张表，这样每张表就只有100万数据。
2、数据索引算法
分表后就需要设计一个机制来保证能快速且准确的获取当前请求的哈希值是存储在哪张数据表的，并在之后去该表中查询具体数据。
我们目前采用的算法是：取邮箱哈希值的头10个字符，并将其由2进制转化为10进制，之后对5001进行取模运算。通过这种方式实际测试来看能非常均匀的将数据分散到每张表中。
3、数据录入
这里是最坑的部分，我反复测试尝试了好几天才找到比较好的方案。
- 尝试在脚本中直接循环生成SQL将数据写入数据库，结果是奇慢无比，1分钟大概4万条，这样算下来全写完得三个月
- 尝试生成批量查询SQL，每次批量10万条，速度略有提升，但仍然在不可接受范围内
- 尝试生成SQL文件，然后使用source命令导入，依旧是速度有提升，但仍不可接受
- 尝试生成CSV文件，并使用MySQL的Load data infile命令，这次速度终于可以了，但因为我们使用的是叠瓦盘的缘故，导致掉速严重。
- 最后的终极方案，先生成5000个CSV文件，然后在SSD环境下导入，之后复制到机械盘存档查询。通过这种方式成功在一晚上的时间里导入了这600G数据。
折腾一圈下来，毛都掉了了。好在最终测试来看，在这50亿行数据里检索一次哈希值就只需要2毫秒，可以说效果超出预期。
本周计划
上周插播的关于Cravatar头像的任务可谓是圆满完成，本周将继续回归主线任务，处理翻译平台余下部分以及应用市场的商家商品上架和提现流程
