电商网站如何在重大节日支撑庞大的访问量和成交量一直是业内人士关注的话题。
京东618过去不久，京东官方公布的数据显示，6月18日当日的下单量超过1500万单，相比去年同期增长超过100%，其中移动端订单量占比超过60%。
京东集团高级副总裁张晨公开表示：“今年618，京东的备战系统没有出现任何问题。”7月4日，京东技术开放日邀请京东各个业务线的负责人，分享京东如何支撑618大促。
不断改进京东技术架构
京东自1998年在北京成立，已经12年。从2010年开始，京东618大促活动已经经历了六年。为了更好支撑大促，京东一直在对系统架构进行优化和改造。
京东商城交易平台总监王晓钟表示，618刚开始的两年，技术不成熟，所以京东开始做改变。他介绍，京东用了四年的时间，才把系统提升到如今的稳定性。
2011年-2012年，京东一直做技术和架构上的突破。
2013年-2014年，整体的技术架构已经稳定，技术上的突破由架构级变成点级，如改进核心代码;此外，他透露，原先管理上跟不上，这两年对管理做了改进，团队更加成熟。
2014年-2015年，多中心交易扩展悄然进行。王晓钟透露，今年618与去年相比，***的不同是今年采用了多中心交易。去年双11结束后，京东开始往多中心交易方向去改造。今年，面向用户的读流量，已经用上了多中心交易。下一步，要实现面向用户写流量的多中心。
下一个攻克难点：面向用户的写流量
王晓钟透露，面向用户的读流量已经达到标准，整个团队下半年的技术攻关重点是写流量。
首先来普及一下这两个概念。读流量：是指用户在浏览电商网站时不能改变的数据，比如商品的名称、商品的价格、商品的库存。写流量：是指用户可以改变的数据，比如账户的余额、优惠券、取消订单等。写流量分为两块，一块是面向用户，用户看到的京东商城;另一块是采销和运营人员看到的商城，他们能改变商品的名称、价格和库存。
读流量的分布没有一致性的问题，相对静止;写流量是动态的。王晓钟分析：“例如，如果一瓶矿泉水通过机房一卖出，机房二也要扣掉一瓶的数，高并发情况下，两个机房同时存在流量。举个例子，北京市还有十瓶矿泉水，两个机房同时接到一单，机房一需要八瓶矿泉水，机房二也需要八瓶矿泉水，总共十六瓶。那这八瓶给谁不给谁?两个机房都能看到库存还有十瓶。***，一定是其中一个机房看到另一个机房的数据，才能解决这个问题，所以这个问题特别难解决。”
事实上，业内写流量的问题不仅存在于京东，支付宝、12306都存在这样的问题，高并发时，数据一致性是非常难解决的。
向MySQL迁移来解决问题
京东资深架构师者文明表示，目前京东95%以上的应用都已经跑在MySQL上。他认为，Oracle的数据库不够灵活，水平扩展有局限限制，非金融类的业务，完全没有必要使用Oracle。
他表示，写流量瓶颈的问题，也可以通过MySQL来解决，主要通过以下几个方面：
1、 把现有放在Oracle数据库上的应用迁移到MySQL上;
2、 对数据库进行水平切分，即拆表拆库;
3、 提升I/O性能，通过优化软件、升级服务器、增加服务器实现;
4、 异步写数据库
者文明表示：“目前京东的写流量没有达到已有业务的瓶颈，但是作为技术部门要提前突破瓶颈，到今年双11就能解决写流量瓶颈的问题。”
编后语：
采访中，王晓钟表示，很多优化都是通过加机器的方式解决，小的瓶颈有很多优化的点，但是大的瓶颈，仍需要通过加机器的方式来解决。整个架构发展经过两个阶段，***个阶段，应用和数据不支持水平扩展，加机器没有用;第二个阶段，支持水平扩展后，加机器很管用。而他认为，面对高并发的大促，临时加机器是不靠谱的，流量都要提前预估好，本次京东618准备了平时10倍的流量。
