淘宝分享

淘宝分享

2011-12-14 16:35:01

url: http://chanelll.blog.163.com/blog/static/1769033482011111441623917/

公司同事去淘宝后问的一些问题，分享下：
1、 数据库相关
a) 问：据说ebay等数据库查询大部分都是单表查询，很少join。
答：淘宝主要表(商品、用户等)也都是单表查询，而且仅使用ID(主键字段)进行查询。原本需要join的地方，都可以先查出相应的ID值列表，再用in(…)的方式进行查询。
评：如果大家都用单表查询，那么垂直拆库就简单了。如果仅用ID进行查询，则水平拆库也简单了。
b) 问：数据库读压力可以通过多个备库解决，写压力如何支持扩展?
答：主要通过水平拆库。目前水平拆库由拆两个变拆三个，仅需最大2分钟切换时间。
评：水平拆库的前提是单表查询，且仅ID查询。
c) 问：读缓存比较简单。是否在用写缓存? 类似秒杀库存如何处理。
答：基本不用写缓存。秒杀处理基本都是异步的，当时不告诉用户是否秒杀生效。事后可根据行为特征自动识别是否秒杀器，最后才根据库存确认各秒杀是否生效。
评：写缓存确实过于复杂，水平拆库可有效降低写压力。秒杀之类的应该异步处理才合适。
d) 问：数据库面临连接数过多问题，如何解决?
答：oracle连接成本较高，mysql较低。目前淘宝已基本全用mysql，支付宝仍用oracle。
         同时淘宝service化较完善，已拆为几百个子系统。多个系统访问相同库时基本都通过相同的service处理，不存在连接浪费。
         支付宝部分系统通过三层DAL共享连接。
评：一般应用建议转向mysql，同时Service化很重要。是否需要三层DAL存争议。
e) 问：分布式事务，跨库事务如何支持?
答：尽量避免用事务。不追求完全一致性，仅追求最终一致性。
评：分布式事务问题很难突破，应尽量通过系统设计角度避免。

2、 搜索相关：这点比较遗憾。因淘宝搜索已由一淘负责，没打听到有价值的内容。

3、 多地IDC机房：
a) 问：是否多地有IDC机房，如何使用?
答：目前仅实现多地的容灾备份和CDN。广告、搜索之类仅只读性的系统，可能考虑分布到多IDC。
评：可考虑将首页、商品详情页、CMS页等，通过squid分布在各地。方案实现比较简单，也可解决大部分用户响应问题。

4、 版本控制
a) 问：是否支持逐步发布到各机器?
答：已实现自动逐步发布。目前基本一天两次发布时间点(白天)。
评：自动发布如果做好了，大家可以白天发布系统了，很诱人啊J 
b) 问：逐步发布时，各版本间如何兼容?
答：主要还是要靠程序员设计时，考虑兼容性处理。

 

5、 团队管理
a) 问：如何对开发人员进行考核激励?
答：基本也无量化考核机制。主要打造氛围，让开发人员自己对质量有愿望， 对质量差的应感到羞愧。
评：看来开发人员量化考核是业界难题，主要还需靠氛围和激发主动性。

一些原本没打算打听的，但听下来觉得比较有意思的点。
1、 自动化：整体感觉淘宝的部署发布、测试自动化已比较成熟。
                  部署发布自动化系统，由中间件团队开发。
                  WebUI的测试自动化系统，由测试团队，基于一个开源的ruby框架开发。Service接口测试自动化，自行开发。自动化测试主要用于回归测试。
2、 安全：专门有个安全团队。可通过用户行为特征，自动识别出部分恶意用户。
3、 流量压力开关：当流量超过一定值时，系统支持将后来的一些流量直接拒绝服务。

总体感受：
1、 淘宝在架构层面已有较多积累，但基本上也没太多高深的技术，太难解决的问题一般通过规避的方法解决。当然一淘的咋样就没了解到。
2、 解决性能问题最终无非三板斧：拆分(拆数据库、拆子系统、竖着拆、横着拆)、缓存(数据缓存、页面缓存)、异步(一些同步处理有性能问题的，就变成异步来处理)