11 武伟峰

京东商城app后台 - 高级软件工程师

我要认证

开源贡献者,有代码洁癖。京东coder。

等级
TA的排名 1k+

etcd集群搭建和使用中常见的报错信息(热key探测系列教程)

etcd的下载地址:https://github.com/etcd-io/etcd/releases当前最新的v3.4.9,我之前用的时候包括目前京东热key线上都是用的3.4.6,下面主要是看一下如何搭建etcd集群。如果是本地测试单点的话,就在上面链接下载对应的操作系统版本,打开后直接启动etcd就算本地启动成功了,启动后就可以用etcdctl控制台进行操作,或者用代码操作etcd即可。集群的话,以linux 3节点集群为例。创建一个sh脚本,如下#!/bin/bash

2020-07-06 17:53:23

京东毫秒级热key探测框架设计与实践,已完美支撑618大促

在拥有大量并发用户的系统中,热key一直以来都是一个不可避免的问题。或许是突然某些商品成了爆款,或许是海量用户突然涌入某个店铺,或许是秒杀时瞬间大量开启的爬虫用户, 这些突发的无法预先感知的热key都是系统潜在的巨大风险。风险是什么呢?主要是数据层,其次是服务层。热key对数据层的冲击显而易见,譬如数据存放在redis或者MySQL中,以redis为例,那个未知的热数据会按照hash规则被存在于某个redis分片上,平时使用时都从该分片获取它的数据。由于redis性能还不错,再加上集群模式,每秒我们

2020-06-28 18:38:53

京东热key探测框架本地压测数据记录,单机(8核)QPS约16万/s,可水平扩展

继上一次全链路压测时,热key框架由于Java低版本(1.8.0_131之前的1.8)获取docker内cpu核数有问题,实则获取的是宿主机的核数,造成线程数量过多,压测瞬间cpu达到100%,问题也记录在了另一篇(https://blog.csdn.net/tianyaleixiaowu/article/details/106092060)。后来找到了问题原因,并成功修复了。然后还修改了一些其他的小问题,总体感觉框架比较稳定了。我就自己做了一些性能方面的压测,分别先后使用了4台、8台、16台、32台机器作

2020-05-25 11:57:40

京东618大促压测时自研中间件暴露出的问题总结,压测级别数十万/秒

前天618大促演练进行了全链路压测,在此之前刚好我的热key探测框架也已经上线灰度一周了,小范围上线了2500台服务器,每秒大概接收几千个key探测,每天大概2-4亿左右,因为量很小,所以框架表现稳定。借着这次压测,刚好可以检验一下热key框架在大流量时的表现。毕竟作为一个新的中间件,里面很多东西还是第一次用,免不得会出一些问题。压测期,我没有去扩容热key的worker集群,还是平时用的3个16C+1个4C8G的组合,3个16核是是主力,4核的是看上限能到什么样。由于之前那一周的平稳表现,导致我有

2020-05-13 14:11:04

4次优化,我把 Redis 性能 “压榨” 到极致!

本文转载自公众号https://mp.weixin.qq.com/s/y4q4Hb9A6xay3pAC_LBm5g我们有个这样的需求:每天每一个抢购商品只能买一次,并且全场抢购商品总购买次数不允许超过5次。那么,整个商品限购的流程大概如下图所示:那么,在每次购买成功商品成功后,发送的MQ大概是这样的(假设当前这笔订单有两件抢购商品):这条消息表示86000000000...

2020-03-19 12:04:17

手写中间件之——并行框架(4 相互依赖模型的建立)

建议学习时,打开代码https://gitee.com/tianyalei/asyncTool 对着代码看。上一篇主要讲了如何实现异步回调,简单回忆一下是如何实现的。java的future的get方法是同步阻塞的,无法达到任务完成后主动回调的目的。netty的future是可以做到回调的,通过addListener的方式,但是为什么addListener后就能回调了,也是通过封装执行单元和回...

2020-01-22 13:46:00

开源异步并行框架,完成任意的多线程编排、阻塞、等待、串并行结合、强弱依赖

本文首发于京东零售公众号,https://mp.weixin.qq.com/s/17OAAbCKQND-AjTdf43TGwnetty是一个经典的网络框架,提供了基于NIO、AIO的方式来完成少量线程支持海量用户请求连接的模型。netty里面充斥了大量的非阻塞回调模式,主要是靠Future/Promise异步模型来实现的。Future是java.util.concurrent.Future...

2020-01-14 19:34:56

手写中间件之——并行框架(3 异步回调如何实现)

上一篇主要讲了任务的编排该如何实现,包括串、并、串并结合。建议一定要手写个小demo去尝试各种基本组合。这一篇主要是讲该如何实现异步回调。如果之前有用过netty的应该知道,netty里大量充斥着“回调”,各种addListener,将各种耗时任务变成了异步带回调的模式。回调是个很有用的模式,譬如我的主线程执行过程中,要执行一个非常耗时的逻辑,自然我们会想到用异步的形式去完成这个耗时逻...

2020-01-07 10:04:23

Netty实现自定义协议

关于协议,使用最为广泛的是HTTP协议,但是在一些服务交互领域,其使用则相对较少,主要原因有三方面:HTTP协议会携带诸如header和cookie等信息,其本身对字节的利用率也较低,这使得HTTP协议比较臃肿,在承载相同信息的情况下,HTTP协议将需要发送更多的数据包; HTTP协议是基于TCP的短连接,其在每次请求和响应的时候都需要进行三次握手和四次挥手,由于服务的交互设计一般都要求能够...

2020-01-06 17:36:00

手写中间件之——并行框架(2 任务编排顺序如何选型和实现)

这一篇我们就要开始手写这个并行框架了。做任何一个项目,都要做的事情都是先定大框架,后拆解任务。那么这个并发框架,要完成上一篇讲的那些所有任务,该如何定大框架呢,如何选型呢?如果大家仔细看了上一篇文章,可以看到该框架的难点和重点,主要有两点,分别是任务的顺序编排和任务结果的回调。如何做任务顺序编排依次来看一下各个基本场景1 全串行这种是最简单的,依次串行即可。假如...

2020-01-03 17:39:03

手写中间件之——并行框架(1 并行框架的应用场景和需求)

我们为什么会需要一个带任务顺序编排的并行框架1 复杂的微服务系统间调用经常会有这样的调用场景:app(或web前端)调用后台的一个接口,该接口接到该请求后,需要调用其他多个微服务来获取数据,最终汇总一个最终结果返回给用户。譬如用户请求“我的订单”,后台在收到请求后,就需要去调用用户详情rpc、商品详情rpc、库存rpc、优惠券rpc等等很多个服务。有些服务是可以并行去请求的,但有些服务...

2020-01-02 11:28:58

使用 Reactor 进行反应式编程

反应式编程(Reactive Programming)这种新的编程范式越来越受到开发人员的欢迎。在 Java 社区中比较流行的是 RxJava 和 RxJava 2。本文要介绍的是另外一个新的反应式编程库 Reactor。反应式编程介绍反应式编程来源于数据流和变化的传播,意味着由底层的执行模型负责通过数据流来自动传播变化。比如求值一个简单的表达式 c=a+b,当 a 或者 b 的值发生变化...

2019-12-31 13:36:50

任意组合、编排的多线程并发框架,支持任意阻塞、等待、串并行组合,回调、超时、默认值等

并发场景可能存在的需求之——任意编排1 多个执行单元的串行请求2 多个执行单元的并行请求3 阻塞等待,串行的后面跟多个并行4 阻塞等待,多个并行的执行完毕后才执行某个5 串并行相互依赖6 复杂场景并发场景可能存在的需求之——每个执行结果的回调传统的Future、CompleteableFuture一定程度上可以完...

2019-12-25 16:29:53

Java中使用etcd,包括基本的set、get、超时设置,watch监听等

etcd的使用文章。etcd来zookeeper类似,常用的主要有set,get,getPrefix:获取指定前缀的所有数据,grant:key的超时设置,watch:监听回调事件,watchPrefix:监听某个前缀的事件,keepAlive:为某个key设置自动续约、自动刷新过期时间。zk的大部分功能,etcd都有。但有一个,譬如虚拟节点,zk可以做到当客户端断开时,立马监听到,etc...

2019-12-12 16:32:15

redis探秘:选择合适的数据结构,减少80%的内存占用,这些点你get到了吗?

本文首发于京东零售平台公众号,https://mp.weixin.qq.com/s/uzuz7rqctQ-bjdRcf1tO9gredis作为目前最流行的nosql缓存数据库,凭借其优异的性能、丰富的数据结构已成为大部分场景下首选的缓存工具。由于redis是一个纯内存的数据库,在存放大量数据时,内存的占用将会非常可观。那么在一些场景下,通过选用合适的数据结构来存储,可以大幅减少内存的占用,...

2019-12-10 09:29:31

使用Retryer优雅地实现对Callable各种各样的重试调用

Runnable和Callable都是多线程编程中常用的接口,通常是通过实现该接口编写业务逻辑后,再由new Thread去发起线程调用。主要区别在于Runnable没有返回值,而Callable有返回值。下面就来看一个重试框架Retryer,针对Callable做的各种重试策略方法。 API 接口调用异常, 网络异常在我们日常开发中经常会遇到,这种情况下我们需要先重试几次调用才能将其标识...

2019-11-28 10:24:45

10G mysql binlog重放并传输到另一台服务器执行,阿里中间件大赛

转载自:https://tianchi.aliyun.com/forum/new_articleDetail.html?spm=5176.11165310.0.0.90a57f61Sy5xTQ&raceId=231600&postsId=2035这个冠军的方案确实赞,10G的mysql binlog重放并传输只用了2秒!总决赛冠军队伍 作死小分队 比赛攻略决赛答...

2018-04-08 16:25:57

分布式环境下对部分热数据(如redis热key,热请求)进行探测,并对探测结果及时同步到各个client实例的JVM内存的方案简述

可先阅读之前的这篇,有赞的热key探测及缓存方案。常见场景突发性的无法预先感知的热点数据请求,或者有阵发性明显热点数据的。譬如突然大量请求都命中了redis的某个分片,造成该redis卡顿,影响其他请求。热key特性如 goodsId=100,突发1万请求该key。譬如突然大量同一个用户的请求某一个或多个接口,呈现出攻击性访问的。热key特性如userId-99= /cart,/c...

2019-11-14 20:36:18

Java简单实现滑动窗口

由于最近有一个统计单位时间内某key的访问次数的需求,譬如每5秒访问了redis的某key超过100次,就取出该key单独处理。这样的单位时间统计,很明显我们都知道有个边界问题,譬如5秒内100次的限制。刚好前4.99秒访问都是0,最后0.01秒来了100次,5.01秒又来了100次。也就是访问有明显的毛刺情况出现,为了弱化这个毛刺情况,我们可以采用滑动窗口。滑动窗口滑动窗口的主要原理...

2019-11-01 17:06:02

有赞的redis热key探测及缓存到jvm内存框架方案

下面这篇文章来自于有赞的知识共享,总体设计还是不错的,但我对其中的一点比较存疑。就是将计算热点key的工作放在客户端这里。因为一个java实例,可能面临巨多的get请求,譬如请求的key数量较多,那么由客户端来记录这些key,并计算key的热度,是一个比较费力且吃内存的事。即便他限制了最大内存量,那可能会漏掉很多key。还有一种,譬如某个key非常热,但是请求分散到了N个实例里,显得单个实...

2019-10-29 10:30:49

查看更多

CSDN身份
  • 博客专家
勋章 我的勋章
  • 领英
    领英
    绑定领英第三方账户获取
  • GitHub
    GitHub
    绑定GitHub第三方账户获取
  • 脉脉勋章
    脉脉勋章
    绑定脉脉第三方账户获得
  • 签到新秀
    签到新秀
    累计签到获取,不积跬步,无以至千里,继续坚持!
  • 技术圈认证(专家版)
    技术圈认证(专家版)
    博客专家完成年度认证,即可获得
  • 新人勋章
    新人勋章
    用户发布第一条blink获赞超过3个即可获得
  • 专栏达人
    专栏达人
    授予成功创建个人博客专栏的用户。专栏中添加五篇以上博文即可点亮!撰写博客专栏浓缩技术精华,专栏达人就是你!
  • 持之以恒
    持之以恒
    授予每个自然月内发布4篇或4篇以上原创或翻译IT博文的用户。不积跬步无以至千里,不积小流无以成江海,程序人生的精彩需要坚持不懈地积累!
  • 1024勋章
    1024勋章
    #1024程序员节#活动勋章,当日发布原创博客即可获得
  • 勤写标兵Lv1
    勤写标兵Lv1
    授予每个自然周发布1篇到3篇原创IT博文的用户。本勋章将于次周周三上午根据用户上周的博文发布情况由系统自动颁发。
  • 原力探索
    原力探索
    参与《原力计划【第二季】——打卡挑战》的文章入选【每日精选】的博主将会获得此勋章。
  • 原力突破
    原力突破
    参与《原力计划【第二季】— 打卡挑战》的文章入选【打卡挑战周榜】的博主,即可获得此勋章。
  • 博客之星-入围
    博客之星-入围
    授予每年博客之星评选结果第21-200名的用户
  • 原力新人
    原力新人
    在《原力计划【第二季】》打卡挑战活动中,成功参与本活动并发布一篇原创文章的博主,即可获得此勋章。