本文曾在“架构师之路”上发布过，近期支援Qcon-AS大会，在微信群里分享了该话题，故对原文进行重新整理与发布。 一、秒杀业务为什么难做 1）im系统，例如qq或者微博，每个人都读自己的数据（好友列表、群列表、个人信息）； 2）微博系统，每个人读你关注的人的数据，一个人读多个人的数据； 3）秒杀系统，库存只有一份，所有人会在集中的时间读和写这些数据，多个人读一个

一、什么是高可用 高可用HA（High Availability）是分布式系统架构设计中必须考虑的因素之一，它通常是指，通过设计减少系统不能提供服务的时间。 假设系统一直能够提供服务，我们说系统的可用性是100%。 如果系统每运行100个时间单位，会有1个时间单位无法提供服务，我们说系统的可用性是99%。 很多公司的高可用目标是4个9，也就是99.99%，这就意味着，系

一、什么是高并发 高并发（High Concurrency）是互联网分布式系统架构设计中必须考虑的因素之一，它通常是指，通过设计保证系统能够同时并行处理很多请求。 高并发相关常用的一些指标有响应时间（Response Time），吞吐量（Throughput），每秒查询率QPS（Query Per Second），并发用户数等。 响应时间：系统对请

上一篇文章“一分钟了解负载均衡的一切”引起了不少同学的关注，评论中大家争论的比较多的一个技术点是接入层负载均衡技术，部分同学持这样的观点： 1）nginx前端加入lvs和keepalived可以替代“DNS轮询” 2）F5能搞定接入层高可用、扩展性、负载均衡，可以替代“DNS轮询” “DNS轮询”究竟是不是过时的技术，是不是可以被其他方案替代，接入层架构技术演进，是本文将要细致讨

零、需求缘起 第一篇文章“一分钟了解负载均衡”和大家share了互联网架构中反向代理层、站点层、服务层、数据层的常用负载均衡方法。 第二篇文章“lvs为何不能完全代替DNS轮询”和大家share了互联网接入层负载均衡需要解决的问题及架构演进。 在这两篇文章中，都强调了“负载均衡是指，将请求/数据【均匀】分摊到多个操作单元上执行，负载均衡的关键在于【均匀】”。 然

什么是负载均衡 负载均衡（Load Balance）是分布式系统架构设计中必须考虑的因素之一，它通常是指，将请求/数据【均匀】分摊到多个操作单元上执行，负载均衡的关键在于【均匀】。   常见的负载均衡方案 常见互联网分布式架构如上，分为客户端层、反向代理nginx层、站点层、服务层、数据层。可以看到，每一个下游都有多个上游调用，只需要做到，每一个上游都均匀访问每一个下游

一、需求缘起 明明架构要求高可用，为何系统中还会存在单点？ 回答：单点master的设计，会大大简化系统设计，何况有时候避免不了单点   在哪些场景中会存在单点？先来看一下一个典型互联网高可用架构。 典型互联网高可用架构： （1）客户端层，这一层是浏览器或者APP，第一步先访问DNS-server，由域名拿到nginx的外网IP （2）负载均衡层，ng

一、需求缘起 Web-Server通常有个配置，最大工作线程数，后端服务一般也有个配置，工作线程池的线程数量，这个线程数的配置不同的业务架构师有不同的经验值，有些业务设置为CPU核数的2倍，有些业务设置为CPU核数的8倍，有些业务设置为CPU核数的32倍。 “工作线程数”的设置依据是什么，到底设置为多少能够最大化CPU性能，是本文要讨论的问题。   二、一些共性认知

一，需求缘起 互联网公司，这样的场景是否似曾相识：   场景一：pm要做一个很大的运营活动，技术老大杀过来，问了两个问题： （1）机器能抗住么？ （2）如果扛不住，需要加多少台机器？   场景二：系统设计阶段，技术老大杀过来，又问了两个问题： （1）数据库需要分库么？ （2）如果需要分库，需要分几个库？   技术上来说，这些都是系统

一、需求缘起 几乎所有的业务系统，都有生成一个记录标识的需求，例如： （1）消息标识：message-id （2）订单标识：order-id （3）帖子标识：tiezi-id 这个记录标识往往就是数据库中的唯一主键，数据库上会建立聚集索引（cluster index），即在物理存储上以这个字段排序。   这个记录标识上的查询，往往又有分页或者排序的业务

引言 其实本来真的没打算写这篇文章，主要是LZ得记忆力不是很好，不像一些记忆力强的人，面试完以后，几乎能把自己和面试官的对话都给记下来。LZ自己当初面试完以后，除了记住一些聊过的知识点以外，具体的内容基本上忘得一干二净，所以写这篇文章其实是很有难度的。 但是，最近问LZ的人实在是太多了，为了避免重复回答，给自己省点力气，干脆就在这里统一回复了。