加入收藏 | 设为首页 | 会员中心 | 我要投稿 核心网 (https://www.hxwgxz.com/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 教程 > 正文

狂揽1592亿!京东京麦平台618备战实践总结

发布时间:2018-07-07 06:34:04 所属栏目:教程 来源:王新栋
导读:【资讯】近日,京东可谓是好事连连,“谷歌 5.5 亿美元投资京东”、“京东 1.2 亿美元增持唯品会股权”、“一年一度的京东 618 狂欢也终于落下帷幕,累计下单金额达 1592 亿元”。 京东 1592 亿元的惊人战绩离不开强大的技术支撑,下面来自京东京麦平台的
副标题[/!--empirenews.page--]

  【资讯】近日,京东可谓是好事连连,“谷歌 5.5 亿美元投资京东”、“京东 1.2 亿美元增持唯品会股权”、“一年一度的京东 618 狂欢也终于落下帷幕,累计下单金额达 1592 亿元”。

  狂揽1592亿!京东京麦平台618备战实践总结

  京东 1592 亿元的惊人战绩离不开强大的技术支撑,下面来自京东京麦平台的资深架构师王新栋给大家揭秘京东年度大考背后的备战实践。

  作为技术研发人员,我们常戏称京东每年只干两件事,一个是 618,另外一个是双 11!

  确实每一次的大促都是一场全兵演练,技术人员在这场战斗中,从团队合作、技术提升、用户意识上都有一个立体的提高。实难想象还有比这样规模的促销更好的锻炼方式。

  京麦平台是目前京东所有商家唯一使用的一站式店铺运营管理平台,商家借助京麦可以实现商品发布、打印订单、出库、订单消息接收等等一系列的日常工作。

  京麦平台更是集合了众多 ISV 厂商为商家提供了更加丰富的功能,更好的赋能于商家。

  京麦平台的技术架构也在随着京东业务的飞速发展不断演化着。从早期的简单 Nginx+Tomcat 部署,到现在功能服务模块化,独立部署,享受着微服务带来的便利,但同时也给我们大促的备战带来了众多挑战。

  狂揽1592亿!京东京麦平台618备战实践总结

  狂揽1592亿!京东京麦平台618备战实践总结

  首先确定自己的备战思路,梳理核心流程、找出薄弱点,对薄弱点具体优化。

  同时协调压测对优化结果验证,优化和压测会有一个反复的过程,后面我们还要实际演练,比如降级开关,防止实际情况发生的时候准备好的功能不可用。

  最后我们要做一轮培训,在工具使用,快速定位问题,历来的教训总结都过一遍。

  从心理层面上我们也要辅导,大促期间发生的问题都不是小问题,研发人员在这种压力下处理问题有时候会变形,我们会在这方面做一次心理疏解。

  这中间我们可以利用几个规则,二八法则,找出 20% 重要核心的功能,比如京麦的登录、交易、价格门消息推送。

  在找薄弱点的时候我们可以试试墨菲定律的几点规则,“可能出错的事总会出错”,“如果你担心某种情况发生,那么它就有可能发生”。

  我们还会找大家一起列出心中最不可能出现问题的系统和功能点来重点对待,没错,是重点对待。

  狂揽1592亿!京东京麦平台618备战实践总结

  我们常用的备战技术,肯定不是重启,回滚,加机器,我个人总结有:

  分离技术

  缓存技术

  SQL 优化

  快速失败

  降级限流

  下面我们来逐一介绍。

  分离技术

  话说“天下大事,合久必分,分久必合”,但在软件架构领域,一直是一个分的趋势。

  比如京麦平台有提供 ISV 的服务、提供京麦自有客户端的服务、提供其他平台的服务,同时还有监控服务,日志服务,消息服务等。

  这需要将业务服务隔离部署,线下分析和线上运行隔离,同时还可以采取线程隔离,比如 JSF 里面为每个不同重要的服务分别一个线程组的方式。

  数据库层面上主从分离,京麦平台的业务都是读多写少,可以充分利用分库的资源。

  还可以再将数据库细分,按照主要业务拆分不同的数据库,结合 RPC 使用,更大降低数据库层面的耦合程度。

  狂揽1592亿!京东京麦平台618备战实践总结

  狂揽1592亿!京东京麦平台618备战实践总结

  缓存技术

  如果软件里面真的有一种银弹的话,我认为就是缓存,当你性能优化遇到瓶颈的时候,当你想抗量的时候,你都会想到缓存。

  这里有一个铁律,那就是,对外暴露的接口一定不能直达数据库。我们常用的缓存是 Redis + JVMcache。

  计算 Redis 穿透率的时候我们可以,通过 UMP 来实现,在一个方法的总入口埋点,比如统计出 1 分钟调用 M 次,在请求 Redis 的入口埋点,统计出 1 分钟调用 N次,计算命中率:N/M。

  在使用 Redis 的时候要注意含有大数值的 key,常常量一上来会造成 Redis 集群的热点访问,直接将单一节点打死。

  这样的情况下我们就要拆分这样的大 key。同时将缓存 DB 化,就是不设置超时时间,这样全部用 Redis 来抗量。

  本地缓存这块我们常用的有 Guava-cache,通过本地缓存我们可以做三级防护,或者做托底数据等。

  如果数据“尺寸较小”、“高频的读取操作”、“变更操作较少”使用这种嵌入式缓存将非常合适。

  狂揽1592亿!京东京麦平台618备战实践总结

  SQL优化

  每次大促前我们都要将系统中性能慢的 SQL 抓出来,而且这种工作投入产出比极高,也就是可以花费较小代价带来极大的性能收益。

  SQL 性能问题,大多数情况下是没有索引引起的,这可能是后续业务变化迅速,上线前代码 review 的遗漏,需要这个时候统一过一遍。

  还有就是索引使用错误,比如索引字段是字符串类型,但是程序中请求 DB 的时候传的是 long 类型,索引失效,表中数量过多,做了一次全表扫描,性能会很差。

  还有时候我们添加索引的时候要看区分度,计算索引区分度的方法是不重复的索引值/总记录数,值越接近 1,说明区分度越高,查询的时候 MySQL 就会过滤掉更多的行数据。

  还有,添加索引最好结合 MySQL 执行计划来判断。有时候做了过多的 join 操作,比如超过 3 张表以上,我们就要想着去拆解这些 SQL 语句。

(编辑:核心网)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

热点阅读