海南网站建设小强,网站建设和管理存在的问题,做宝玉石交易的网站有哪些,微网站怎么注册账号服务高并发、高性能、高可用实现方案 软件开发的三高指标#xff1a;高并发、高性能、高可用。 高并发方面要求QPS 大于 10万#xff1b;高性能方面要求请求延迟小于 100 ms#xff1b;高可用方面要高于 99.99%(4个9) 一、高并发#xff1a; 高并发是现在互联网分布式框架设…服务高并发、高性能、高可用实现方案 软件开发的三高指标高并发、高性能、高可用。 高并发方面要求QPS 大于 10万高性能方面要求请求延迟小于 100 ms高可用方面要高于 99.99%(4个9) 一、高并发 高并发是现在互联网分布式框架设计必须要考虑的因素之一它是可以保证系统能同时并发处理很多请求对于高并发来说它的指标有 1、响应时间系统对进来的请求反应的时间比如你打开一个页面需要1秒那么这1秒就是响应时间 2、吞吐量吞吐量指每秒能处理多少请求数量 3、每秒查询率QPSQueries Per Second每秒响应请求数和吞吐量差不多 4、并发用户数同时承载正常使用系统功能的用户数量。例如一个即时通讯系统同时在线量一定程度上代表了系统的并发用户数 提高QPS的架构策略 Redis、MQ、多线程 1、负载均衡 高并发首选方案就是集群化部署一台服务器承载的QPS有限多台服务器叠加效果就会有明显提升。 集群化部署就需要考虑如何将流量转发到服务器集群这里就需要用到负载均衡如LVSLinux Virtual Server和nginx。 常用的负载均衡算法有轮询法、随机法、源地址哈希法、加权轮询法、加权随机法、最小连接法等。 业务实战对于千万级流量的秒杀业务一台LVS扛不住流量洪峰通常需要 10 台左右其上面用DDNSDynamic DNS做域名解析负载均衡。搭配高性能网卡单台LVS能够提供百万以上并发能力。 注意 LVS 负责网络四层协议转发无法按 HTTP 协议中的请求路径做负载均衡所以还需要 Nginx 2、池化技术 复用单个连接无法承载高并发如果每次请求都新建连接、关闭连接考虑到TCP的三次握手、四次挥手需要花费大量开销。 池化技术的核心是资源的“预分配”和“循环利用”常用的池化技术有线程池、连接池、进程池、对象池、内存池、协程池。 连接池的几个重要参数最小连接数、空闲连接数、最大连接数 3、流量漏斗风控拦截 以上的几种方式是正向方式提升系统QPS我们也可以逆向思维做减法拦截非法请求将核心能力留给正常业务请求。 互联网高并发流量并不都是纯净的也有很多恶意流量比如黑客攻击、恶意爬虫、黄牛、秒杀器等我们需要设计流量拦截器将哪些非法的、无资格的、低优先级的流量过滤掉风控掉减轻系统的并发压力。 拦截器分层: 网关和 WAFWeb Application FirewallWeb 应用防火墙 采用封禁攻击者来源 IP、拒绝带有非法参数的请求、按来源 IP 限流、按用户 ID 限流等方法 风控分析。借助大数据能力分析订单等历史业务数据对同ip多个账号下单、或者下单后支付时间过快等行为有效识别并给账号打标记提供给业务团队使用 下游的每个tomcat实例应用本地内存缓存化将一些库存存储在本地一份做前置校验。当然为了尽量保持数据的一致性有定时任务从 Redis 中定时拉取最新的库存数据并更新到本地内存缓存中 4、直接读写缓存不可直接读写关系型数据库 MySQL即使使用分库分表读写分离完美的连接池配置等也无法抵挡qps大于10W带来的冲击。 我们必须使用内存缓存缓存预热读多级缓存JVM缓存其次Redis写消息队列最后写入MySQL 5、多级缓存 Redis目前是缓存的第一首选.单机可达6-8万的qps,在面对高并发的情况下,我们可以手动的水平扩容,以达到应对qps可能无线增长的场景。但是这种做法也存在弊端,因为redis是单线程的,并且会存在热点问题 虽然redis内部用crc16算法做了hash打散,但是同一个key还是会落到一个单独的机器上,就会使机器的负载增加,redis典型的存在缓存击穿和缓存穿透两个问题,尤其在秒杀这个场景中,如果要解决热点问题,就变的比较棘手 这个时候多级缓存就必须要考虑了,典型的在秒杀的场景中,单sku商品在售卖开始的瞬间,qps会急剧上升.而我们这时候需要用memeryCache来挡一层,memeryCache是多线程的,比redis拥有更好的并发能力,并且它是天然可以解决热点问题的。有了memeryCache,我们还需要localCache本地缓存,这是一种以内存换速度的方式。本地缓存会接入用户的第一层请求,如果它找不到,接下来走memeryCache然后走redis这套流程下来可以挡住百万的qps 6、多线程 多线程并发处理提高处理速度CountDownLatch 7、优化IO 如将多次单个的请求优化为一次批量请求减少网络IO 对应MySQL就是批量插入批量查询 因为每次建立连接数据交互释放连接都会消耗大量的资源同时涉及到用户态到核心态的切换 8、优雅打印日志 高并发情况下日志打印不当会占用程序的IO增加响应耗时。如果日志量过大会导致磁盘打满 ①异步打印日志控制日志输出的长度 ②基于白名单的日志打印线上配置了白名单用户请求才打印日志避免大量的无效日志输出 其他 机器扩容 大流量到来之前对服务机器进行扩容分化消化流量。 如Redis缓存单机可达6-8W的qps在高并发到来之前可以手动或配置自动伸缩扩容以达到应对qps可能无限增长的场景。 高并发服务发散 假设qps为10W每个请求读写数据为1KB那么10W个请求每秒钟读写就达到1GB1分钟则60GB这对于底层的数据存储与访问都是巨大的压力。 二、高性能 高性能指程序处理速度非常快所占内存少且CPU占用率低。高性能的指标经常和高并发的指标紧密相关想要提升性能那么就要提高系统并发能力两者互相捆绑在一起。 有哪些因素会影响系统的性能 业务代码的逻辑设计算法实现是否高效、架构设计 业务系统CPU、内存、磁盘等性能 下游系统的性能 业务链路的长度 请求/响应数据包大小 用户网络环境 怎么样提高性能呢 1、避免因为IO阻塞让CPU闲置导致CPU的浪费。 当系统处理大量磁盘IO操作的时候由于CPU和内存的速度远高于磁盘可能导致CPU耗费太多时间等待磁盘返回处理的结果。对于这部分在IO上的开销称为iowait。 磁盘有个性能指标IOPS即每秒读写次数性能较好的固态硬盘IOPS 大概在 3 万左右。对于秒杀系统如果单节点QPS在10万每次请求产生3条日志那么日志的写入QPS在 30W/s磁盘根本扛不住 Linux 有一种特殊的文件系统tmpfs临时文件系统它是一种基于内存的文件系统由操作系统管理。当我们写磁盘的时候实际是写到内存中当日志文件达到我们的设置阈值操作系统会将日志写到磁盘中并将tmpfs中的日志文件删除 这种批量化、顺序写大大提升了磁盘的吞吐性能 2、避免多线程间增加锁来保证同步导致并行系统串行化 3、避免创建、销毁、维护太多进程、线程导致操作系统浪费资源在调度上 4、高性能缓存如Redis。 对热点数据从缓存中读取来提升热点数据的访问性能避免热点数据每次都从数据库中读取给数据库带来压力 1、无锁化 大多数情况下多线程处理处理可以提高并发性能 1串行无锁 无锁串行最简单的实现方式可能就是单线程模型了如 redis/Nginx 都采用了这种方式。 网络编程模型中主线程负责处理IO事件当主线程MainReactor accept一个新连接之后从众多的SubReactor选取一个进行注册通过创建一个Channel与IO线程进行绑定此后该连接的读写都在同一个线程执行无需进行同步 主从Reactor职责链模型 2结构无锁 利用硬件支持的原子操作可以实现无锁的数据结构如CAS原子操作 2、零拷贝 零拷贝博客 3、序列化 当将数据写入文件、发送到网络时通常需要序列化技术从其读取时需要进行反序列化。 序列化作为传输数据的表示形式与网络框架和通信协议是解耦的。如网络框架 taf 支持 jce、json 和自定义序列化HTTP 协议支持 XML、JSON 和流媒体传输等 1序列化分类 ①内置类型 指编程语言内置支持的类型如 java 的 java.io.Serializable。这种类型由于与语言绑定不具有通用性而且一般性能不佳一般只在局部范围内使用 ②文本类型 一般是标准化的文本格式如 XML、JSON。这种类型可读性较好且支持跨平台具有广泛的应用。主要缺点是比较臃肿网络传输占用带宽大 ③二进制类型 采用二进制编码数据组织更加紧凑支持多语言和多平台。常见的有 Protocol Buffer/Thrift/MessagePack/FlatBuffer 等 2性能指标 衡量序列化/反序列化主要有三个指标 ①序列化之后的字节大小 ②序列化/反序列化的速度 ③CPU 和内存消耗 其中性能最好的是FlatBuffer其次是Protobuf 3选型考量 ①性能 CPU 和字节占用大小是序列化的主要开销。在基础的 RPC 通信、存储系统和高并发业务上应该选择高性能高压缩的二进制序列化。一些内部服务、请求较少 Web 的应用可以采用文本的 JSON浏览器直接内置支持 JSON ②易用性 丰富数据结构和辅助工具能提高易用性减少业务代码的开发量。现在很多序列化框架都支持 List、Map 等多种结构和可读的打印 ③通用性 现代的服务往往涉及多语言、多平台能否支持跨平台跨语言的互通是序列化选型的基本条件 ④兼容性 现代的服务都是快速迭代和升级一个好的序列化框架应该有良好的向前兼容性支持字段的增减和修改等 ⑤扩展性 序列化框架能否低门槛的支持自定义的格式有时候也是一个比较重要的考虑因素 4、池化 其本质是通过创建池子提高对象复用减少重复创建、销毁的开销。 常见的池化技术有内存池、线程池、连接池、对象池等 1内存池 我们都知道在 C/C中分别使用 malloc/free 和 new/delete 进行内存的分配其底层调用系统调用 sbrk/brk。频繁的调用系统调用分配释放内存不但影响性能还容易造成内存碎片内存池技术旨在解决这些问题。正是这些原因C/C中的内存操作并不是直接调用系统调用而是已经实现了自己的一套内存管理。 malloc 的实现主要有三大实现。 ①、ptmallocglibc 的实现。 ②、tcmallocGoogle 的实现。 ③、jemallocFacebook 的实现。 tcmalloc和jemalloc性能差不多ptmalloc性能不如两者redis和mysql可以指定使用哪个malloc我们可以根据需要选择更适合的malloc。 内存管理的三个层次 2线程池 线程池使应用能更加充分利用CPU、内存、网络、IO等系统资源。限制线程的创建数量并复用已创建的线程从而提高系统的性能。 线程的创建需要开辟虚拟机栈、本地方法栈、程序计数器等线程私有的内存空间 线程的销毁时需要回收这些系统资源。因此频繁的创建和销毁线程会浪费大量的系统资源增加并发编程风险。 另外在服务器负载过大的时候如何让新的线程等待或者友好地拒绝服务这些都是线程本身无法解决的。所以需要通过线程池协调多个线程并实现类似主次线程隔离、定时执行、周期执行等任务。线程池的作用包括 ①利用线程池管理并复用线程、控制最大并发数等 ②实现任务线程队列缓存策略和拒绝机制 ③实现某些与时间相关的功能如定时执行、周期执行 ④隔离线程环境分类或者分组 分组通过配置两个或多个线程池不同的任务使用不同的线程池如较慢的任务与其他任务分隔开避免任务间互相影响 分类可以分为核心和非核心核心线程池一直存在不会被回收非核心可能对空闲一段时间后的线程进行回收从而节省系统资源等到需要时在按需创建放入池子中 线程池总结 3连接池 常见的连接池有数据库连接池、Redis连接池、TCP连接池等。 其主要目的是通过复用连接来减少创建和释放连接的开销。连接池实现通常需要考虑以下几个问题 ①初始化时机 启动即初始化或惰性初始化通常使用启动即初始化的方式 启动初始化可以减少一些加锁操作和需要时可以直接使用缺点是可能造成服务启动缓慢或者启动后没有任务处理造成资源浪费 惰性初始化是使用的时候再去创建这种方式可能有助于减少资源占用但是面对突发的任务请求然后瞬间去创建一堆连接可能会造成系统响应慢甚至响应失败。 ②连接数目 权衡所需的连接数连接数太少则可能造成任务处理缓慢太多不但使任务处理慢还会过度消耗系统资源 ③连接取出 当连接池已经无可用连接时是一直等待直到有可用连接还是分配一个新的临时连接 ④连接归还 当连接使用完毕且连接池未满时将连接放入连接池包括 3 中创建的临时连接否则关闭 ⑤连接有效性检测 长时间空闲连接和失效连接需要关闭并从连接池移除。常用的检测方法有使用时检测和定期检测 数据库连接池 4对象池 严格来说各种池都是对象池模式的应用。 对象池跟上面其他池一样也是缓存一些对象从而避免大量创建同一个类型的对象同时限制了实例的个数如 ①Redis 中 0-9999 整数对象就通过采用对象池进行共享 ②在游戏开发中对象池模式经常使用如进入地图时怪物和 NPC 的出现并不是每次都是重新创建而是从对象池中取出 ③mdm中RedisTemplate对象缓存、uvcas中TalosProducer对象缓存 public static final MapString, RedisTemplateString, Object REDIS_TEMPLATE_MAP new ConcurrentHashMap();// 当前线程本地变量RdmContext rdmContext RdmContext.currentContext();RedisProperties redisProperties rdmContext.getRedisProperties();String token rdmContext.getToken();// 看是否有缓存的redisTemplateRedisTemplateString, Object redisTemplate RdmCache.REDIS_TEMPLATE_MAP.get(token);if (redisTemplate ! null) {rdmContext.setRedisTemplate(redisTemplate);return;}// 创建RedisTEmplate并缓存// 缓存起来RdmCache.REDIS_TEMPLATE_MAP.put(token, redisTemplate); 5、并发化 1请求并发 如果一个任务需要处理多个子任务可以将没有依赖关系的子任务并发化这种场景在后台开发很常见。如一个请求需要查询 3 个数据分别耗时 T1、T2、T3如果串行调用总耗时 TT1T2T3。对三个任务执行并发总耗时 Tmax(T1,T 2,T3)。同理写操作也如此。对于同种请求还可以同时进行批量合并减少 RPC 调用次数 2冗余请求 冗余请求指的是同时向后端服务发送多个同样的请求谁响应快就是使用谁其他的则丢弃。这种策略缩短了客户端的等待时间但也使整个系统调用量猛增一般适用于初始化或者请求少的场景 6、异步化 对于处理耗时长的任务如果采用同步等待的方式会严重降低系统的吞吐量可以采用异步化进行解决。 1调用异步化 在进行一个耗时的RPC调用或者任务处理时常用的异步化方式如下 ①Callback 异步回调通过注册一个回调函数然后发起异步任务当任务执行完毕时会回调用户注册的回调函数从而减少调用端等待时间。这种方式会造成代码分散难以维护定位问题也相对困难 ②Future 当用户提交一个任务时会立刻先返回一个 Future然后任务异步执行后续可以通过 Future 获取执行结果 //异步并发任务FutureResponse f1 Executor.submit(query1);//处理其他事情doSomething();//获取结果Response res1 f1.getResult(); ③CPS Continuation-passing style可以对多个异步编程进行编排组成更复杂的异步处理并以同步的代码调用形式实现异步效果 CPS 将后续的处理逻辑当作参数传递给 Then 并可以最终捕获异常解决了异步回调代码散乱和异常跟踪难的问题 Java 中的 CompletableFuture 和 C PPL 基本支持这一特性。典型的调用形式如下
void handleRequest(const Request req)
{return req.Read().Then([](Buffer inbuf){return handleData(inbuf);}).Then([](Buffer outbuf){return handleWrite(outbuf);}).Finally(){return cleanUp();});
} 2流程异步化 一个业务流程往往伴随着调用链路长、后置依赖多等特点这会同时降低系统的可用性和并发处理能力 可以采用对非关键依赖进行异步化解决如MQ 7、缓存 从单核 CPU 到分布式系统从前端到后台缓存无处不在 缓存是原始数据的一个复制集其本质就是空间换时间主要是为了解决高并发读 1缓存的使用场景 缓存是空间换时间的艺术使用缓存能提高系统的性能。 注意不要为了所谓的提高性能不计成本的使用缓存而是要看场景。 ①一旦生成后基本不会变化的数据 ②读密集型或存在热点的数据 ③计算代价大的数据 ④千人一面的数据 不适合使用缓存的场景 ①写多读少更新频繁 ②对数据一致性要求严格 2缓存的分类 ①进程级缓存 缓存的数据直接在进程地址空间内这可能是访问速度最快使用最简单的缓存方式了。 主要的缺点是受制于进程空间大小能缓存的数据量有限进程重启缓存数据会丢失。一般用于缓存数据量不大的场景如JVM缓存 ②集中式缓存 缓存的数据集中在一台机器上如共享内存。这类缓存容量主要受制于机器内存大小而且进程重启后数据不丢失。常用的集中式缓存中间件有单机版 redis、memcache 等 ③分布式缓存 缓存的数据分布在多台机器上通常需要采用特定算法如 Hash进行数据分片将海量的缓存数据均匀的分布在每个机器节点上。常用的组件有Memcache客户端分片、Codis代理分片、Redis Cluster集群分片 ④多级缓存 指在系统中的不同层级的进行数据缓存以提高访问效率和减少对后端存储的冲击 本地缓存caffeine 外部缓存Redis 3缓存一些好的实践 ①动静分离 对于一个缓存对象可能分为很多种属性这些属性中有的是静态的有的是动态的。在缓存的时候最好采用动静分离的方式 ②慎用大对象 如果缓存对象过大每次读写开销非常大并且可能会卡住其他请求特别是在 redis 这种单线程的架构中。典型的情况是将一堆列表挂在某个 value 的字段上或者存储一个没有边界的列表这种情况下需要重新设计数据结构或者分割 value 再由客户端聚合 ③过期设置 尽量设置过期时间减少脏数据和存储占用但要注意过期时间不能集中在某个时间段 ④超时设置 缓存作为加速数据访问的手段通常需要设置超时时间而且超时时间不能过长如 100ms 左右否则会导致整个请求超时连回源访问的机会都没有 ⑤缓存隔离 首先不同的业务使用不同的 key防止出现冲突或者互相覆盖。其次核心和非核心业务进行通过不同的缓存实例进行物理上的隔离 ⑥失败降级 用缓存需要有一定的降级预案缓存通常不是关键逻辑特别是对于核心服务如果缓存部分失效或者失败应该继续回源处理不应该直接中断返回 ⑦容量控制 使用缓存要进行容量控制特别是本地缓存缓存数量太多内存紧张时会频繁的 swap 存储空间或 GC 操作从而降低响应速度 ⑧业务导向 以业务为导向不要为了缓存而缓存。对性能要求不高或请求量不大分布式缓存甚至数据库都足以应对时就不需要增加本地缓存否则可能因为引入数据节点复制和幂等处理逻辑反而得不偿失 ⑨监控告警 对大对象、慢查询、内存占用等进行监控 8、分片 分片即将一个较大的部分分成多个较小的部分在这里我们分为数据分片和任务分片。 对于数据分片不同系统的拆分技术术语如 region、shard、vnode、partition等统称为分片 分片可以说是一箭三雕的技术将一个大数据集分散在更多节点上单点的读写负载随之也分散到了多个节点上同时还提高了扩展性和可用性 数据分片小到编程语言标准库里的集合大到分布式中间件无所不在如 Java线程安全的ConcurrentHashMap采取分段机制按照哈希或者取模将对象放置到某个分段中减少锁争用 分布式消息中间件 Kafka 中对 topic 也分成了多个 partition每个 partition 互相独立可以并发读写 1分片策略 进行分片时要尽量均匀的将数据分布在所有节点上以平摊负载。 如果分布不均会导致倾斜使得整个系统性能的下降常见的分片策略如下 ①区间分片 基于一段连续关键字的分片保持了排序适合进行范围查找减少了垮分片读写。区间分片的缺点是容易造成数据分布不均匀导致热点。如根据ID范围进行分片 常见的还有按时间范围分片则最近时间段的读写操作通常比很久之前的时间段频繁 ②随机分片 按照一定的方式如哈希取模进行分片这种方式数据分布比较均匀不容易出现热点和并发瓶颈 缺点就是失去了有序相邻的特性如进行范围查询时会向多个节点发起请求 ③组合 对区间分片和随机分片的一种折中采取了两种方式的组合。通过多个键组成复合键其中第一个键用于做哈希随机其余键用于进行区间排序 社交场景如微信朋友圈、QQ 说说、微博等以用户 id发布时间(user_id,pub_time)的组合找到用户某段时间的发表记录 2二级索引 二级索引通常用来加速特定值的查找不能唯一标识一条记录使用二级索引需要两次查找查找。 关系型数据库和一些KV数据库都支持二级索引如MySQL中的非聚簇索引ES倒排索引通过term找到文档都是二级索引。 ①本地二级索引 二级索引存储在与关键字相同的分区中即索引和记录在同一个分区中。 这样对于写操作时都在一个分区里进行不需要跨分区操作。但是对于读操作需要聚合其他分区上的数据。 ②全局二级索引 按索引值本身进行分区与关键字独立。 这样对于读取某个索引的数据时都在一个分区里进行而对于写操作需要跨多个分区。 3路由策略 路由策略决定如何将数据请求发送到指定的节点包括分片调整后的路由。 路由策略通常有三种方式客户端路由、代理路由、集群路由 ①客户端路由 客户端直接操作分片逻辑感知分片和节点的分配关系并直接连接到目标节点。 Memcache就是采用这种方式实现的分布式 ②代理层路由 客户端的请求发送到代理层由其转发到对应的数据节点上。 很多分布式系统都采用了这种方式如业界的基于redis实现的分布式存储codis等 ③集群路由 由集群实现分片路由客户端连接任意节点如果该节点存在请求的分片则处理否则将请求转发到合适的节点或者告诉客户端重定向到目标节点 如redis cluster就采用了这种方式 以上几种方式各有优缺点客户端路由实现相对简单但对业务入侵较强。 代理层路由对业务透明但增加了一层网络传输。对性能有一定影响同时在部署上也相对复杂。 集群路由对业务透明且比代理路由少了一层结构节约成本但实现更复杂且不合理的策略会增加多次网络传输 4动态平衡 在学习平衡二叉树和红黑树的时候我们都知道由于数据的插入删除会破坏其平衡性。为了保持树的平衡在插入删除后我们会通过左旋右旋动态调整树的高度以保持再平衡。在分布式数据存储也同样需要再平衡只不过引起不平衡的因素更多了主要有以下几个方面 ①读写负载增加需要更多CPU ②数据规模增加需要更多磁盘和内存 ③数据节点故障需要其他节点接替 业务有很多产品支持动态平衡调增如redis cluster的reshardingHDFS/kafka的rebalance等。常见的方式如下 ①固定分区 创建远超节点数的分区数为每个几点分配多个分区。 如果新增节点可从现有的节点上均匀移走几个分区从而达到平衡删除节点反之。 ②动态分区 自动增减分区数当分区数据增长到一定阀值时则对进行拆分。当分区数据缩小到一定阀值时对分区进行合并。 类似于B树的分裂删除操作。很多存储组件都采用了这种方式如 HBase Region 的拆分合并TDSQL 的 Set Shard。 这种方式的优点是自动适配数据量扩展性好。使用这种分区需要注意的一点如果初始化分区为一个刚上线请求量就很大的话会造成单点负载高通常采取预先初始化多个分区的方式解决如 HBase 的预分裂。 5分库分表 当数据库的单表/单机数据量很大时会造成性能瓶颈为了分散数据库的压力提高读写性能需要采取分而治之的策略进行分库分表。通常在以下情况下需要进行分库分表 ①单表的数据量达到了一定的量级如 mysql 一般为千万级读写的性能会下降。这时索引也会很大性能不佳需要分解单表 ②数据库吞吐量达到瓶颈需要增加更多数据库实例来分担数据读写压力 分库分表按照特定的条件将数据分散到多个数据库和表中分为垂直切分和水平切分两种模式。 ①垂直切分 按照一定规则如业务或模块类型将一个数据库中的多个表分布到不同的数据库上 优点 ①切分规则清晰业务划分明确 ②可以按照业务的类型、重要程度进行成本管理扩展也方便 ③数据维护简单 缺点 ①不同表分到了不同的库中无法使用表连接 Join。不过在实际的业务设计中也基本不会用到 join 操作一般都会建立映射表通过两次查询或者写时构造好数据存到性能更高的存储系统中 ②事务处理复杂原本在事务中操作同一个库的不同表不再支持。这时可以采用柔性事务或者其他分布式事物方案 ②水平切分 按照一定规则如哈希或取模将同一个表中的数据拆分到多个数据库上 可以简单理解为按行拆分拆分后的表结构是一样的 优点 ①切分后表结构一样业务代码不需要改动 ②能控制单表数据量有利于性能提升 缺点 ①join、count、记录合并、排序、分页等问题需要跨节点处理 ②相对复杂需要实现路由策略 综上所述垂直切分和水平切分各有优缺点通常情况下这两种模式会一起使用。 6任务分片 任务分片将一个任务分成多个子任务并行处理加速任务的执行通常涉及到数据分片如归并排序首先将数据分成多个子序列先对每个子序列排序最终合成一个有序序列。 在大数据处理中Map/Reduce 就是数据分片和任务分片的经典结合 9、存储 1读写分离 大多数业务都是读多写少为了提高系统处理能力因为写时会加锁无法读可以采用读写分离的方式将主节点用于写从节点用于读 读写分离架构有以下几个特点 ①数据库服务为主从架构可以为一主一从或者一主多从 ②主节点负责写操作从节点负责读操作 ③主节点将数据复制到从节点基于基本架构可以变种出多种读写分离的架构如主-主-从、主-从-从。主从节点也可以是不同的存储如 mysqlredis 读写分离的主从架构一般采用异步复制会存在数据复制延迟的问题适用于对数据一致性要求不高的业务。可采用以下几个方式尽量避免复制滞后带来的问题 ①写后读一致性 即读自己的写适用于用户写操作后要求实时看到更新。典型的场景是用户注册账号或者修改账户密码后紧接着登录此时如果读请求发送到从节点由于数据可能还没同步完成用户登录失败这是不可接受的。针对这种情况可以将自己的读请求发送到主节点上查看其他用户信息的请求依然发送到从节点 ②二次读取 优先读取从节点如果读取失败或者跟踪的更新时间小于某个阀值则再从主节点读取 ③关键业务读写主节点非关键业务读写分离 ④单调读 保证用户的读请求都发到同一个从节点避免出现回滚的现象。如用户在 M 主节点更新信息后数据很快同步到了从节点 S1用户查询时请求发往 S1看到了更新的信息。接着用户再一次查询此时请求发到数据同步没有完成的从节点 S2用户看到的现象是刚才的更新的信息又消失了即以为数据回滚了 2动静分离 动静分离将经常更新的数据和更新频率低的数据进行分离。最常见于 CDN一个网页通常分为静态资源图片/js/css 等和动态资源JSP、PHP 等采取动静分离的方式将静态资源缓存在 CDN 边缘节点上只需请求动态资源即可减少网络传输和服务负载 在数据库和 KV 存储上也可以采取动态分离的方式 ①在缓存中将一个缓存对象中的静态字段和动态字段分开缓存 ②在数据库中动静分离更像是一种垂直切分将动态和静态的字段分别存储在不同的库表中减小数据库锁的粒度同时可以分配不同的数据库资源来合理提升利用率 3冷热分离 冷热分离可以说是每个存储产品和海量业务的必备功能Mysql、ElasticSearch、CMEM、Grocery 等都直接或间接支持冷热分离 将热数据放到性能更好的存储设备上冷数据下沉到廉价的磁盘从而节约成本。 如保留7天的热数据超过7天的数据任务其为冷数据进行迁移 4重写轻读 ①关键写降低读的关键性如异步复制保证主节点写成功即可从节点的读可容忍同步延迟 ②写重逻辑读轻逻辑将计算的逻辑从读转移到写。适用于读请求的时候还要进行计算的场景常见的如排行榜是在写的时候构建而不是在读请求的时候再构建 5数据异构 数据异构主要是按照不同的维度建立索引关系以加速查询 如京东、天猫等网上商城一般按照订单号进行了分库分表。由于订单号不在同一个表中要查询一个买家或者商家的订单列表就需要查询所有分库然后进行数据聚合 可以采取构建异构索引在生成订单的时同时创建买家和商家到订单的索引表这个表可以按照用户 id 进行分库分表 10、队列 在系统应用中不是所有的任务和请求必须实时处理很多时候数据也不需要强一致性而只需保持最终一致性有时候我们也不需要知道系统模块间的依赖在这些场景下队列技术大有可为 1应用场景 ①异步处理 业务请求的处理流程通常很多有些流程并不需要在本次请求中立即处理这时就可以采用异步处理 ②流量削峰 高并发系统的性能瓶颈一般在 I/O 操作上如读写数据库。面对突发的流量可以使用消息队列进行排队缓冲 ③系统解耦 解决系统之间的强调用关系去除阻塞调用改为异步消息 ④数据同步 消息队列可以起到数据总线的作用特别是在跨系统进行数据同步时。如通过 RabbitMQ 在写 Mysql 时将数据同步到 Redis从而实现一个最终一致性的分布式缓存 ⑤柔性事务 传统的分布式事务采用两阶段协议或者其优化变种实现当事务执行时都需要争抢锁资源和等待在高并发场景下会严重降低系统的性能和吞吐量甚至出现死锁 互联网的核心是高并发和高可用一般将传统的事务问题转换为柔性事务 柔性事务的核心流程为 1分布式事务发起方在执行第一个本地事务前向 MQ 发送一条事务消息并保存到MQ服务端MQ 消费者无法感知和消费该消息 ①② 2事务消息发送成功后开始进行单机事务操作 ③ a. 如果本地事务执行成功则将 MQ 服务端的事务消息更新为正常状态 ④ b.如果本地事务执行时因为宕机或者网络问题没有及时向 MQ 服务端反馈则之前的事务消息会一直保存在 MQ。MQ 服务端会对事务消息进行定期扫描如果发现有消息保存时间超过了一定的时间阀值则向 MQ 生产端发送检查事务执行状态的请求 ⑤ c.检查本地事务结果后 ⑥如果事务执行成功则将之前保存的事务消息更新为正常状态否则告知 MQ 服务端进行丢弃 3消费者获取到事务消息设置为正常状态后则执行第二个本地事务 ⑧。如果执行失败则通知 MQ 发送方对第一个本地事务进行回滚或正向补偿 2应用分类 ①缓冲队列 队列的基本功能就是缓冲排队如 TCP 的发送缓冲区网络框架通常还会再加上应用层的缓冲区。使用缓冲队列应对突发流量时使处理更加平滑从而保护系统 在大数据日志系统中通常需要在日志采集系统和日志解析系统之间增加日志缓冲队列以防止解析系统高负载时阻塞采集系统甚至造成日志丢弃同时便于各自升级维护。如数据采集系统中采用 Kafka 作为日志缓冲队列 ②请求队列 对用户的请求进行排队网络框架一般都有请求队列如 spp 在 proxy 进程和 work 进程之间有共享内存队列taf 在网络线程和 Servant 线程之间也有队列主要用于流量控制、过载保护和超时丢弃等 ③任务队列 将任务提交到队列中异步执行最常见的就是线程池的任务队列 ④消息队列 用于消息投递主要有点对点和发布订阅两种模式常见的有 RabbitMQ、RocketMQ、Kafka 等 三、高可用 可用性指一个系统处在可用工作状态的时间的比例 高可用让系统趋近于100%的高度可用 具体衡量指标 MTBFMean Time Between Failure平均故障间隔时间平均无故障工作时间即系统可用时长单位为小时 MTTRMean Time To Repair系统从故障到恢复正常所耗费的时间 SLAService-Level Agreement服务等级协议用于评估服务可用性等级。计算公式是 MTBF/(MTBFMTTR) 我们常说的可用性高于99.99%4个9是指指标SLA高于99.99%。
可用性年故障时间日故障时间90% 1个936.5天2.4小时99% 2个93.65天14.4分钟99.9% 3个90.365天8小时1.44分钟99.99% 4个90.0365天52分钟8.6秒99.999% 5个90.00365天5分钟0.86秒技术架构高可用有哪些策略 多云架构、异地多活、异地备份 主备切换如Redis缓存、MySQL数据库主备节点会实时数据同步、备份。如果主节点不可用自动切换到备用节点 微服务无状态化架构、业务集群化部署有心跳检测能最短时间检测到不可用的服务 通过熔断、限流解决流量过载问题提供过载保护 重视web安全解决攻击和XSS问题 1、系统拆分 早前的系统都是单体系统比如电商业务会员、商品、订单、物流、营销等模块都堆积在一个系统。每到节假日搞个大促活动系统扩容时一扩全扩一挂全挂。只要一个接口出了问题整个系统都不可用。 因此面对庞大的单体系统我们要对其做系统拆分为微服务架构。按照DDD领域驱动设计Domain-DrivenDesign的思想将一个复杂的业务拆分成若干个子系统每个子系统负责专属的业务功能做好垂直化建设各个子系统之间做好边界隔离降低风险蔓延。 2、解耦 软件开发有个重要原则“高内聚、低耦合” 小到接口抽象、MVC分层大到SOLID原则23种设计模式。核心都是降低不同模块间的耦合度避免一处错误改动影响到整个系统 思路如Spring AOP、事件驱动模型 3、异步 同步指一个线程在执行请求的时候若该请求需要一段时间才能返回信息那么这个线程将会阻塞一直等待下去直到收到返回信息才继续执行下去。 如果是非实时响应的动作可以采用异步来完成线程不需要一直等待而是继续执行后面的逻辑 如线程池、消息队列 举例下单操作我们关心的是订单是否创建成功能否进行后续的付款流程 至于其他的业务动作如短信通知、邮件通知、生成订单快照超时取消任务这些非核心动作用户并不是很关心这些操作我们可以采用消息队列异步执行。在下单成功在数据库插入订单记录之后发送消息到MQ然后返回用户成功监听消息的线程来完成这些操作 4、重试 重试主要体现在远程的RPC调用受网络抖动、线程资源阻塞等因素影响请求无法及时响应。 为了提升用户体验调用方可以通过 重试 方式再次发送请求尝试获取结果。 接口重试是一把双刃剑虽然客户端收到了响应超时结果但是我们无法确定服务端是否已经执行完成。如果盲目地重试可能会带来严重后果。比如银行转账。 重试通常跟幂等组合使用如果一个接口支持了 幂等那你就可以随便重试。 重试方案 ①sisyphus ②spring retry 幂等方案 ①插入前先执行查询操作看是否存在再决定是否插入。 ②增加唯一索引。 ③建防重表。 ④引入状态机比如付款后订单状态调整为已付款SQL 更新记录前增加条件判断。 ⑥增加分布式锁。 ⑦采用 Token 机制服务端增加 token 校验只有第一次请求是合法的 5、补偿 通过补偿来实现数据的最终一致性 注意补偿操作有个重要前提业务能接受短时间内的数据不一致 业务补偿根据处理的方向分为两部分 ①正向 多个操作构成一个分布式事务如果部分成功。部分失败我们会通过最大努力机制将失败的任务推到成功状态 ②逆向 通过反向操作将部分成功任务恢复到初始状态 补偿实现方式 ①本地建表方式存储相关数据然后通过定时任务扫描提取并借助反射机制触发执行 ②也可以采用简单的消息中间件构建业务消息体由下游的消费任务执行。如果失败可以借助 MQ 的重试机制多次重试 6、故障转移 故障转移一般指主备切换、缩短故障时间 当系统出现故障时首要任务不是立马查找原因考虑到故障的复杂性定位排查要花些时间等问题修复好SLA也降了好几个档。更好的解决方案就是故障转移 故障转移当发现故障节点的时候不是尝试修复它而是立即把它隔离同时将流量转移到正常节点上。这样通过故障转移不仅减少了MTTR提升了SLA还为修复故障节点赢得了足够的时间。 ①对等节点可直接转移切换 ②节点分主备时转移时需要进行主备切换 如何发现故障并自动转移 一般采用某种故障检测机制比如心跳机制备份节点定期发送心跳包当多数节点未收到主节点的心跳包表示主节点故障需要进行切换 切换到哪个备节点 一般采用paxos、raft等分布式一致性算法在多个备份节点中选出新主节点 主备切换大致分为三步 1故障自动侦测auto-detect采用健康检查心跳等手段自动侦测故障节点 2自动转移failover当侦测到故障节点后采用摘除流量、脱离集群等方式隔离故障节点将流量转移到正常节点 3自动恢复failback当故障节点恢复正常后自动将其加入集群中确保集群资源与故障前一致 7、多活策略 容灾备份策略并不能保证万事大吉 在一些极端情况如机房断电、机房火灾、地震、山洪等不可抗力因素所有的服务器主、备可能都同时出现故障全部无法对外提供服务导致整体业务瘫痪。 为了降低风险保证服务的24小时可用性我们可以采用多活策略 常见的多活方案有同城多活、两地三中心、三地五中心、异地双活、异地多活等 8、隔离 隔离属于物理层面的分割将若干的系统低耦合设计独立部署从物理上隔开。 每个子系统有自己独立的代码库独立开发独立发布。一旦出现故障也不会相互干扰。当然如果不同子系统间有相互依赖这种情况比较特殊需要有默认值或者异常特殊处理这属于业务层面解决方案。 隔离属于分布式技术的衍生产物我们最常见的微服务解决方案。 将一个大型的复杂系统拆分成若干个微服务系统这些微服务子系统通常由不同的团队开发、维护独立部署服务之间通过 RPC 远程调用。 隔离使得系统间边界更加清晰故障可以更加隔离开来问题的发现与解决也更加快速系统的可用性也更高 9、限流提供过载保护 高并发系统如果遇到流量洪峰超过了当前系统的承载能力要怎么办 一种方案如果照单全收CPU、内存、Load负载飙的很高最后处理不过来所有请求都超时无法正常响应 另一种方案将多余的流量舍弃掉 限流定义 限制到达系统的并发请求数量保证系统能够正常响应部分用户请求而对于超过限制的流量则通过拒绝服务的方式保证系统整体的可用性 限流的原理跟熔断有点类似都是通过判断某个条件来确定是否执行某个策略。但是又有所区别熔断触发过载保护该节点会暂停服务直到恢复。限流则是只处理自己能力范围之内的请求超量的请求会被限流 根据作用范围限流分为单机版限流、分布式限流 1、单机版限流 主要借助于本机内存来实现计数器比如通过 AtomicLong#incrementAndGet()但是要注意之前不用的 key 定期做清理释放内存 纯内存实现无需和其他节点统计汇总性能最高。但是优点也是缺点无法做到全局统一化的限流 2、分布式限流 单机版限流仅能保护自身节点但无法保护应用依赖的各种服务并且在进行节点扩容、缩容时也无法准确控制整个服务的请求限制。 而分布式限流以集群为维度可以方便的控制这个集群的请求限制从而保护下游依赖的各种服务资源 限流支持的多个维度 ①整个系统一定时间内比如每分钟处理多少请求 ②单个接口一定时间内处理多少流量 ③单个 IP、城市、渠道、设备 id、用户 id 等在一定时间内发送的请求数 ④如果是开放平台则为每个 appkey 设置独立的访问速率规则 限流算法主要有 计数器限流、滑动窗口限流、令牌桶限流、漏桶限流 10、熔断提供过载保护 所谓过载保护是指负载超过系统的承载能力时系统会自动采取保护措施确保自身不被压垮。 熔断其实是对调用链路中某个资源出现不稳定状态时如调用超时或异常比例升高对这个资源的调用进行限制让请求快速失败避免影响到其他的资源而导致联机错误。 例子熔断触发条件往往跟系统节点的承载能力和服务质量有关比如 CPU 的使用率超过 90%请求错误率超过 5%请求延迟超过 500ms 它们中的任意一个满足条件就会出现熔断。 熔断的主要方式是使用断路器阻断故障服务器的调用。 断路器有三种状态关闭、打开、半打开 ①关闭Closed状态在这个状态下请求都会被转发给后端服务。同时会记录请求失败的次数当请求失败次数在一段时间超过一定次数就会进入打开状态 ②打开Open状态在这个状态下熔断器会直接拒绝请求返回错误而不去调用后端服务。同时会有一个定时器时间到的时候会变成半打开状态。目的是假设服务会在一段时间内恢复正常 ③半打开Half Open状态在这个状态下熔断器会尝试把部分请求转发给后端服务目的是为了探测后端服务是否恢复。如果请求失败会进入打开状态成功情况下会进入关闭状态同时重置计数 11、降级 降级是系统保护的一种重要手段 为了使有限资源发挥最大价值我们会临时关闭一些非核心功能减轻系统压力并将有限资源留给核心业务 比如电商大促业务在峰值时刻系统抵挡不住全部的流量时系统的负载、CPU 的使用率都超过了预警水位可以对一些非核心的功能进行降级降低系统压力比如把商品评价、成交记录等功能临时关掉。弃车保帅保证 创建订单、支付 等核心功能的正常使用 总结下来降级是通过暂时关闭某些非核心服务或者组件从而保护核心系统的可用性。 12、超时控制 在分布式环境下服务响应慢可能比宕机危害更大失败只是暂时的但调用延迟会导致占用的资源得不到释放在高并发情况下会造成整个系统崩溃 如何合理设置超时时间 收集系统之间的调用日志统计比如说 99% 的响应时间是怎样的然后依据这个时间来指定超时时间 超时处理策略 ①服务超时释放资源响应失败 如数据库配置超时时间超时则终止操作释放资源 jdbc配置 connectTimeout表示等待和MySQL建立socket连接的超时时间默认值0表示不超时单位毫秒建议30000 socketTimeout表示客户端和MySQL建立socket后读写socket时的等待超时时间 ②由于网络波动、节点异常的原因导致的请求超时可以采用服务降级的方式为请求提供兜底的数据响应避免用户界面处于长时间停顿 高可用设计理论 CAPConsistency、Availability、Partition tolerance此理论人尽皆知最终会在CP和AP中权衡找到满足BASEBasically Available、Soft state、Eventually consistent的平衡结果 高可用设计要素 冗余确保对系统操作至关重要的任何元素都有一个额外的冗余组件这些组件可以在发生故障时接管。 监控从正在运行的系统中收集数据并检测组件何时发生故障或停止响应。 故障转移一种手动或自动机制。如果监控显示活动组件发生故障该机制可以从当前活动的组件切换到冗余组件。 上述三要素逻辑也很清晰要实现高可用不管是否存在状态要先有冗余或备份当真正出现故障的时候要有监控手段监控到故障发生故障发生后可以通过故障转移组件快速转移到之前的冗余组件中保证服务不中断。 高可用方案设计需要从哪些角度讨论和思考 首先应用侧、支撑侧、运维侧的设计方式方法不同。 应用侧高可用除了可以通过上述提到的冗余、集群、负载均衡等做到快速的故障转移还包括熔断、限流、容错、降级、应急等保障手段框架组件的超时及重试策略、异步调用、幂等性设计来补充。 支撑侧或称基础设施平台需要一整套高可用相关的监控指标满足故障的提前预警、快速报警、可视化监控和分析。常见指标包括请求量、请求错误率、平均延时、HTTP状态以及系统资源消耗相关指标等。 运维侧中关键一点是DevOps自动化发布、灰度发布、优雅发布、版本控制、健康检查等能力可以在业务发生故障前和发生故障时帮助应用最大程度减小服务不可用时长。 文章转载自： http://www.morning.rqgbd.cn.gov.cn.rqgbd.cn http://www.morning.lcbgf.cn.gov.cn.lcbgf.cn http://www.morning.junmap.com.gov.cn.junmap.com http://www.morning.xscpq.cn.gov.cn.xscpq.cn http://www.morning.dfhkh.cn.gov.cn.dfhkh.cn http://www.morning.rqgjr.cn.gov.cn.rqgjr.cn http://www.morning.rpwm.cn.gov.cn.rpwm.cn http://www.morning.rfldz.cn.gov.cn.rfldz.cn http://www.morning.lqchz.cn.gov.cn.lqchz.cn http://www.morning.bpknt.cn.gov.cn.bpknt.cn http://www.morning.sxbgc.cn.gov.cn.sxbgc.cn http://www.morning.kfqzd.cn.gov.cn.kfqzd.cn http://www.morning.mksny.cn.gov.cn.mksny.cn http://www.morning.touziyou.cn.gov.cn.touziyou.cn http://www.morning.rscrj.cn.gov.cn.rscrj.cn http://www.morning.tfpbm.cn.gov.cn.tfpbm.cn http://www.morning.kcwkt.cn.gov.cn.kcwkt.cn http://www.morning.zlrsy.cn.gov.cn.zlrsy.cn http://www.morning.ho-use.cn.gov.cn.ho-use.cn http://www.morning.zxhpx.cn.gov.cn.zxhpx.cn http://www.morning.djpps.cn.gov.cn.djpps.cn http://www.morning.pmxw.cn.gov.cn.pmxw.cn http://www.morning.cjqcx.cn.gov.cn.cjqcx.cn http://www.morning.fnjrh.cn.gov.cn.fnjrh.cn http://www.morning.bxsgl.cn.gov.cn.bxsgl.cn http://www.morning.pjtw.cn.gov.cn.pjtw.cn http://www.morning.hpkr.cn.gov.cn.hpkr.cn http://www.morning.rxkl.cn.gov.cn.rxkl.cn http://www.morning.qpnmd.cn.gov.cn.qpnmd.cn http://www.morning.bdzps.cn.gov.cn.bdzps.cn http://www.morning.nlrp.cn.gov.cn.nlrp.cn http://www.morning.nzwp.cn.gov.cn.nzwp.cn http://www.morning.yrxcn.cn.gov.cn.yrxcn.cn http://www.morning.pqktp.cn.gov.cn.pqktp.cn http://www.morning.nzmqn.cn.gov.cn.nzmqn.cn http://www.morning.lhhdy.cn.gov.cn.lhhdy.cn http://www.morning.snlxb.cn.gov.cn.snlxb.cn http://www.morning.yqtry.cn.gov.cn.yqtry.cn http://www.morning.bxqry.cn.gov.cn.bxqry.cn http://www.morning.gyfhk.cn.gov.cn.gyfhk.cn http://www.morning.wwklf.cn.gov.cn.wwklf.cn http://www.morning.jpzcq.cn.gov.cn.jpzcq.cn http://www.morning.xltdh.cn.gov.cn.xltdh.cn http://www.morning.sypzg.cn.gov.cn.sypzg.cn http://www.morning.jklns.cn.gov.cn.jklns.cn http://www.morning.kfstq.cn.gov.cn.kfstq.cn http://www.morning.ngqty.cn.gov.cn.ngqty.cn http://www.morning.jxfsm.cn.gov.cn.jxfsm.cn http://www.morning.qkskm.cn.gov.cn.qkskm.cn http://www.morning.tkfnp.cn.gov.cn.tkfnp.cn http://www.morning.jljwk.cn.gov.cn.jljwk.cn http://www.morning.krdb.cn.gov.cn.krdb.cn http://www.morning.clpkp.cn.gov.cn.clpkp.cn http://www.morning.lmctj.cn.gov.cn.lmctj.cn http://www.morning.ldmtq.cn.gov.cn.ldmtq.cn http://www.morning.krgjc.cn.gov.cn.krgjc.cn http://www.morning.stsnf.cn.gov.cn.stsnf.cn http://www.morning.fygbq.cn.gov.cn.fygbq.cn http://www.morning.zwsgl.cn.gov.cn.zwsgl.cn http://www.morning.tsynj.cn.gov.cn.tsynj.cn http://www.morning.rttxx.cn.gov.cn.rttxx.cn http://www.morning.wwkft.cn.gov.cn.wwkft.cn http://www.morning.yfstt.cn.gov.cn.yfstt.cn http://www.morning.plwfx.cn.gov.cn.plwfx.cn http://www.morning.rrbhy.cn.gov.cn.rrbhy.cn http://www.morning.21r000.cn.gov.cn.21r000.cn http://www.morning.mjzgg.cn.gov.cn.mjzgg.cn http://www.morning.nqcts.cn.gov.cn.nqcts.cn http://www.morning.ejknty.cn.gov.cn.ejknty.cn http://www.morning.gqjwz.cn.gov.cn.gqjwz.cn http://www.morning.hsflq.cn.gov.cn.hsflq.cn http://www.morning.c7622.cn.gov.cn.c7622.cn http://www.morning.hcxhz.cn.gov.cn.hcxhz.cn http://www.morning.lrzst.cn.gov.cn.lrzst.cn http://www.morning.sxcwc.cn.gov.cn.sxcwc.cn http://www.morning.tqldj.cn.gov.cn.tqldj.cn http://www.morning.yltyz.cn.gov.cn.yltyz.cn http://www.morning.ypbdr.cn.gov.cn.ypbdr.cn http://www.morning.kczkq.cn.gov.cn.kczkq.cn http://www.morning.jgnjl.cn.gov.cn.jgnjl.cn
