前言现在已经有很多公司在使用HikariCP了，HikariCP还成为了SpringBoot默认的连接池，伴随着SpringBoot和微服务，HikariCP 必将迎来广泛的普及。下面陈某带大家从源码角度分析一下HikariCP为什么能够被Spring Boot 青睐，文章目录如下：目录零、类图和流程图开始前先来了解下HikariCP获取一个连接时类间的交互流程，方便下面详细流程的阅读。获取连接时的类间交互：图1一、主流程1：获取连接流程HikariCP获取连接时

导读微服务中的监控分根据作用领域分为三大类，Logging，Tracing，Metrics。Logging - 用于记录离散的事件。例如，应用程序的调试信息或错误信息。它是我们诊断问题的依据。比如我们说的ELK就是基于Logging。 Metrics - 用于记录可聚合的数据。例如，队列的当前深度可被定义为一个度量值，在元素入队或出队时被更新；HTTP 请求个数可被定义为一个计数器，新请求到来时进行累。prometheus专注于Metrics领域。 Tracing - 用于记录请求范围内的信息。

背景在复杂分布式系统中，往往需要对大量的数据和消息进行唯一标识。如在美团点评的金融、支付、餐饮、酒店、猫眼电影等产品的系统中，数据日渐增长，对数据分库分表后需要有一个唯一ID来标识一条数据或消息，数据库的自增ID显然不能满足需求；特别一点的如订单、骑手、优惠券也都需要有唯一ID做标识。此时一个能够生成全局唯一ID的系统是非常必要的。概括下来，那业务系统对ID号的要求有哪些呢？全局唯一性：不能出现重复的ID号，既然是唯一标识，这是最基本的要求。 趋势递增：在MySQL InnoDB引擎中使用的是聚集

很多做软件开发同学的梦想都是成为一名架构师，而架构师的核心工作就是做好软件设计。软件设计是软件开发过程中的一个重要环节，那么如何进行软件设计，其输出标准又是什么呢？软件设计过程中，如何和各个相关方沟通，使软件设计能同时满足用户的功能需求和非功能需求，并降低公司的开发成本？　前期思考　　很多软件开发同学的职业规划都是架构师，试想这样一个场景，如果公司安排你做架构师，让你在项目开发前期进行了一些架构设计。你该如何开展你的工作？ 应该如何说出你的工作成果？ 你如何确定你的设计是否满足用户需求的.

1. 背景概述 随着移动互联网的兴起，微服务架构的流行，现在很多大的系统会根据业务功能等因素划分成一个一个的微服务，那么在我们的应用中就会有很多rpc接口调用，为了高可用，一般都是双机房部署，当某个机房挂掉的时候可以去调用另外一个机房的服务进行重试，当A机房服务a比如连续N次不可用，或者1分钟内M次不可用，则把这个A机房的这个服务a标记1分钟内不可用，1分钟后再去探活，探活频率可以为1分钟内3次可用则标记该服务可用，这种RPC跨机房重试按理都应该在rpc框架去做，但是如果rpc某个版本没有提供...

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

1.背景介绍 我们在工作中开发的业务系统都要接入监控系统并配置上报警信息，当某个业务系统的某个方法调用性能飚高，或者可用率下降的时候，我们通过报警能及时发现并处理，监控系统可以按照秒，分钟,小时看这个方法的执行调用情况,类似下图，那么这种监控系统我们是否考虑过业界有哪些实现？以及这种监控系统的原理是啥？底层存储的数据结构是啥？2. 原理分析 通常我们的业务系统...

秒杀抢购系统的成功平稳运行，有一些需要注意的知识点。1 高并发，以及刷接口等黑客请求对服务端的负载冲击2 高并发时带来的超卖，即商品数量的控制3 高负载下，下单的速度和成功率的保证4 其他以秒杀单品为例，如抢小米手机。解决方案探讨：第一步 限制前端发来的请求量譬如定在了周二10点开启抢购，那么在之前的一周时间内，都会有预约通知，或者普通的用户浏览。通过预约量、浏览...

引言本文讲述如何去构建一个日志系统，用到了哪些技术？为什么用这些技术？遇到的问题及优化的过程，希望给大家在实践中提供一些参考。这是一个有关于日志的项目，负责收集、处理、存储、查询京东卖家相关操作的日志，这里就叫它“卖家日志”。在日常的开发过程中，可能对日志这个词并不陌生，例如常接触到的Log4j、slf4j等等，这些日志工具通常用来记录代码运行的情况，当系统出问题时，可以通过查看日志及时的...

单点登录SSO（Single Sign On）说得简单点就是在一个多系统共存的环境下，用户在一处登录后，就不用在其他系统中登录，也就是用户的一次登录能得到其他所有系统的信任。单点登录在大型网站里使用得非常频繁，例如像阿里巴巴这样的网站，在网站的背后是成百上千的子系统，用户一次操作或交易可能涉及到几十个子系统的协作，如果每个子系统都需要用户认证，不仅用户会疯掉，各子系统也会为这种重复认证授权的逻辑搞...

（1）为什么要用缓存集群这篇文章，咱们来聊聊热点缓存的架构优化问题。其实使用缓存集群的时候，最怕的就是热key、大value这两种情况，那啥叫热key大value呢？简单来说，热key，就是你的缓存集群中的某个key瞬间被数万甚至十万的并发请求打爆。大value，就是你的某个key对应的value可能有GB级的大小，导致查询value的时候导致网络相关的故障问题。这篇文章，我们就来聊聊热k...

 最近有个需求，要支持批量打印用户订单部分信息，考虑个技术方案如下 定义一个freemaker模板，把订单信息放到freemaker模板里，然后通过freemaker把数据合并成一个html字符串，然后通过itext把html信息转成对应的pdf1引入POM  <dependency> <groupId>com.itextpdf</...

我们在做系统的时候，有时候会遇到迁移数据或者处理任务（任务量又比较大），比如把redis的数据取出来做一些操作，然后处理完的数据在存到hbase我们需要考虑到数据处理过程中失败情况，需要处理高并发去执行，具体怎么设计，怎么做呢，有一种简单的方式如下：1我们先把任务数据存到redis任务队列里2定义一个bean启动3个线程来处理   线程1的：从任务队列取出数据，同时存到备份队列...

1、简介TransmittableThreadLocal 是Alibaba开源的、用于解决 “在使用线程池等会缓存线程的组件情况下传递ThreadLocal” 问题的 InheritableThreadLocal 扩展。若希望 TransmittableThreadLocal 在线程池与主线程间传递，需配合 TtlRunnable 和 TtlCallable 使用。2、使用场景下面是几...

实习生张大胖这是个代码写得很烂的电商系统，只要运行一段时间，服务器就会出现Out Of Memory。别人都忙得四脚朝天，于是实习生张大胖被抓了壮丁去研究为什么会出现OOM。刚入行的张大胖技术水平一般，“装模作样”地看代码，研究日志，请教老员工，一个星期过去了，还是一无所获。周一例行的项目会议上， 大家似乎要看张大胖的笑话了，没想到他却提了一个歪招：“这个OOM问题非常复杂，一时半会儿也解决不了，...

1前言Java帝国在诞生之初就提供了集合、线程、IO、网络等常用功能，从C和C++领地那里吸引了大量程序员过来加盟，但是却有意无意地忽略了一个重要的功能： 输出日志。对于这一点，IO大臣其实非常清楚， 日志是个很重要的东西， 因为程序运行起来以后， 基本上就是一个黑盒子，如果程序的行为和预料的不一致，那就是出现Bug了，如何去定位这个Bug 呢?   

如果你正好处在中小型研发团队……中小型研发团队很多，而社区在中小型研发团队架构实践方面的探讨却很少。中小型研发团队特别是 50 至 200 人的研发团队，在早期的业务探索阶段，更多关注业务逻辑，快速迭代以验证商业模式，很少去关注技术架构。这时如果继续按照原有的架构及研发模式，会出现大量的问题，再也无法玩下去了。能不能有一套可直接落地、基于开源、成本低，可快速搭建的中间件及架构升

一、缘起很多时候，业务有定时任务或者定时超时的需求，当任务量很大时，可能需要维护大量的timer，或者进行低效的扫描。 例如：58到家APP实时消息通道系统，对每个用户会维护一个APP到服务器的TCP连接，用来实时收发消息，对这个TCP连接，有这样一个需求：“如果连续30s没有请求包（例如登录，消息，keepalive包），服务端就要将这个用户的状态置为离线”。 

一、缘起很多时候，业务有“在一段时间之后，完成一个工作任务”的需求。 例如：滴滴打车订单完成后，如果用户一直不评价，48小时后会将自动评价为5星。一般来说怎么实现这类“48小时后自动评价为5星”需求呢？ 常见方案：启动一个cron定时任务，每小时跑一次，将完成时间超过48小时的订单取出，置为5星，并把评价状态置为已评价。假设订单表

转自http://mp.weixin.qq.com/s/CCRa-qbgnNYSI4b10q4F9g在之前的一篇缓存穿透、缓存并发、缓存失效之思路变迁文章中介绍了关于缓存穿透、并发的一些常用思路，但是个人感觉文章中没有明确一些思路的使用场景，本文将继续深化与大家共同探讨，同时也非常感谢这段时间给我提宝贵建议的朋友们（注：本文中提到的缓存可以理解为Redis）。缓存穿透与并发方案

很多朋友估计没有做过这一块，争取最简洁的语言描述清楚。一、业务简述从业务上看    整个智能广告系统，主要分为：1）业务端：广告主的广告后台2）展现端：用户实际访问的页面业务端，广告主主要有两类行为：1）广告设置行为：例如设置投放计划，设置地域，类别，关键字，竞价等2）效果查看行为：例如广告展示次数是多少，

1分钟系列 【缘起】用户中心是几乎每一个公司必备的基础服务，用户注册、登录、信息查询与修改都离不开用户中心。 当数据量越来越大时，需要多用户中心进行水平切分。最常见的水平切分方式，按照uid取模分库：通过uid取模，将数据分布到多个数据库实例上去，提高服务实例个数，降低单库数据量，以达到扩容的目的。 水平切分之后：

一、缘起很多公司，技术经常遇到这样的场景：1）硬件升级，要换一台高配机器2）网络重新规划，若干服务器要调整机架3）服务器当机，要重新部署恢复服务… 更具体的，如上图：数据库换了一个ip，此时往往连接此数据库的上游需要修改配置重启，如果数据库有很多上游调用方，改配置重启的调用方会很多，每次换ip的成本往往很高，成为大家共性的痛点。

一、缘起随着互联网业务的越来越复杂，用户量与流量越来越大，“服务化分层”是架构演进的必由之路。如上图：站点应用会调用服务，上游服务调用底层服务，依赖关系会变得非常复杂。 对于同一个服务，它有多个上游调用。为了保证高可用，一个底层服务往往是若干个节点形成一个集群提供服务。如上图：用户中心服务user-service有三个节点，ip1/ip2/i

转自 https://mp.weixin.qq.com/s/j6OuJ8KwClWaJokofiN8wQ作者｜郑治国编辑｜GaryAPI Gateway（API GW / API 网关），顾名思义，是出现在系统边界上的一个面向 API 的、串行集中式的强管控服务，这里的边界是企业 IT 系统的边界，主要起到隔离外部访问与内部系统的作用。在微服务概念的流行之前，API 网关的实体就已经诞

本文，将介绍数据库架构设计中的一些基本概念，常见问题以及对应解决方案，为了便于读者理解，将以“用户中心”数据库为例，讲解数据库架构设计的常见玩法。 一、用户中心用户中心是一个常见业务，主要提供用户注册、登录、信息查询与修改的服务，其核心元数据为：User(uid, uname, passwd, sex, age,nickname, …)其中：

一、缘起上周讨论了两期环形队列的业务应用：《高效定时任务的触发》《延迟消息的快速实现》 两期的均有大量读者提问：任务、延迟消息都放在内存里，万一重启了怎么办？能否保证消息必达？ 今天就简单聊聊消息队列（MsgQueue）的消息必达性架构与流程。 二、架构方向MQ要想尽量消息必达，架构上有两个核心设计点：

一、双主保证高可用MySQL数据库集群常使用一主多从，主从同步，读写分离的方式来扩充数据库的读性能，保证读库的高可用，但此时写库仍然是单点。 在一个MySQL数据库集群中可以设置两个主库，并设置双向同步，以冗余写库的方式来保证写库的高可用。 二、并发引发不一致数据冗余会引发数据的一致性问题，因为数据的同步有一个时间差，并发的写入可能导致数据同步失败，

作为一个合格的架构师，需要熟悉网络架构，服务器架构，其次才是应用程序开发。1负载均衡，让一堆机器来对外提供服务 常见的负载均衡方案有很多，比如DNS域名解析，nginx反向代理，根据ISO七层网络模型里，其中四层，七层负载均衡，我们主要看下面的几个 1）Cisco以太网通道，原理见下图  2）Windows NLB技术  3）Linux LVS技术 见下图

1美好的旧时光我经常怀念三十年前那美好的旧时光， 工作很轻松， 生活很悠闲。上班的时候偶尔有些HTTP的请求发到我这里， 我简单的看一下， 取出相对应的html文档，图片，发回去就可以了， 然后就可以继续喝茶聊天。我的创造者们对我很好， 他们制定的一个简单HTTP协议， 就是请求加响应，  尤其是我不用记住是谁刚刚发了HTTP请求

电商的秒杀和抢购，对我们来说，都不是一个陌生的东西。然而，从技术的角度来说，这对于Web系统是一个巨大的考验。当一个Web系统，在一秒钟内收到数以万计甚至更多请求时，系统的优化和稳定至关重要。这次我们会关注秒杀和抢购的技术实现和优化，同时，从技术层面揭开，为什么我们总是不容易抢到火车票的原因？ 一、大规模并发带来的挑战 在过去的工作中，我曾经面对过5w每秒的高并发秒杀功能，