├── DESIGN.md ├── JAVA.md └── README.md /DESIGN.md: -------------------------------------------------------------------------------- 1 | - [一、ES篇](#一es篇) 2 | - [1、概述](#1概述) 3 | - [特点](#特点) 4 | - [功能](#功能) 5 | - [场景](#场景) 6 | - [竞品分析](#竞品分析) 7 | - [对比](#对比) 8 | - [2、基本概念](#2基本概念) 9 | - [IK分词器](#ik分词器) 10 | - [索引（类数据库）](#索引类数据库) 11 | - [映射（类表设计）](#映射类表设计) 12 | - [文档（数据）](#文档数据) 13 | - [3、高级特性](#3高级特性) 14 | - [映射高级](#映射高级) 15 | - [**地理坐标点数据类型**](#地理坐标点数据类型) 16 | - [动态映射](#动态映射) 17 | - [DSL高级](#dsl高级) 18 | - [**聚合分析**](#聚合分析) 19 | - [**智能搜索**](#智能搜索) 20 | - [4、实战](#4实战) 21 | - [写优化](#写优化) 22 | - [读优化](#读优化) 23 | - [零停机索引重建方案](#零停机索引重建方案) 24 | - [DeepPaging性能解决方案](#deeppaging性能解决方案) 25 | - [二：Docker&K8S篇](#二dockerk8s篇) 26 | - [Why Docker](#why-docker) 27 | - [核心概念](#核心概念) 28 | - [基本操作](#基本操作) 29 | - [实战](#实战) 30 | - [三、Netty篇](#三netty篇) 31 | - [核心组件](#核心组件) 32 | - [1、整体结构](#1整体结构) 33 | - [2、逻辑架构](#2逻辑架构) 34 | - [网络传输](#网络传输) 35 | - [**1、五种IO模型的区别**](#1五种io模型的区别) 36 | - [2、Reactor多线程模型](#2reactor多线程模型) 37 | - [3、拆包粘包问题](#3拆包粘包问题) 38 | - [4、自定义协议](#4自定义协议) 39 | - [5、WriteAndFlush](#5writeandflush) 40 | - [内存管理](#内存管理) 41 | - [1、堆外内存](#1堆外内存) 42 | - [2、**数据载体ByteBuf**](#2数据载体bytebuf) 43 | - [3、**内存分配jemalloc**](#3内存分配jemalloc) 44 | - [4、jemalloc 架构](#4jemalloc-架构) 45 | - [5、内存池设计（待补充）](#5内存池设计待补充) 46 | - [6、Recycle对象池（待补充）](#6recycle对象池待补充) 47 | - [7、零拷贝技术](#7零拷贝技术) 48 | - [高性能数据结构](#高性能数据结构) 49 | - [1、FastThreadLocal](#1fastthreadlocal) 50 | - [2、**HashedTimerWheel**](#2hashedtimerwheel) 51 | - [3、MpscQueue](#3mpscqueue) 52 | - [4、select、poll、epoll的区别](#4selectpollepoll的区别) 53 | - [四、LEETCODE](#四leetcode) 54 | - [【Python语法】](#python语法) 55 | - [【背包模板】](#背包模板) 56 | - [【回溯模板】](#回溯模板) 57 | - [【并查集模板】](#并查集模板) 58 | - [【拓扑排序模板】](#拓扑排序模板) 59 | - [**【单调栈模板】**](#单调栈模板) 60 | - [【二分模板】](#二分模板) 61 | - [【动态规划模板】](#动态规划模板) 62 | - [「**单串问题**」](#单串问题) 63 | - [「**单串加状态问题**」](#单串加状态问题) 64 | - [「**经典双串LCS问题**」](#经典双串lcs问题) 65 | - [「区间动态规划」](#区间动态规划) 66 | - [**「区间分治动态规划」**](#区间分治动态规划) 67 | - [【滑动窗口】](#滑动窗口) 68 | - [【前缀和】](#前缀和) 69 | - [【双指针】](#双指针) 70 | - [【深度优先】](#深度优先) 71 | - [【广度优先】](#广度优先) 72 | - [【图论】](#图论) 73 | - [五、实战算法篇](#五实战算法篇) 74 | - [**1、**URL黑名单（布隆过滤器）](#1url黑名单布隆过滤器) 75 | - [2、词频统计（分文件）](#2词频统计分文件) 76 | - [**3、未出现的数**（bit数组）](#3未出现的数bit数组) 77 | - [**4、重复URL**（分机器）](#4重复url分机器) 78 | - [**5、TOPK搜索（小根堆）**](#5topk搜索小根堆) 79 | - [**6、中位数（单向二分查找）**](#6中位数单向二分查找) 80 | - [**7、短域名系统（缓存）**](#7短域名系统缓存) 81 | - [**8、海量评论入库（消息队列）**](#8海量评论入库消息队列) 82 | - [**9、在线/并发用户数（Redis）**](#9在线并发用户数redis) 83 | - [10、热门字符串（前缀树）](#10热门字符串前缀树) 84 | - [11、红包算法](#11红包算法) 85 | - [11、手写快排](#11手写快排) 86 | - [12、手写归并](#12手写归并) 87 | - [13、手写堆排](#13手写堆排) 88 | - [14、手写单例](#14手写单例) 89 | - [15、手写LRUcache](#15手写lrucache) 90 | - [**16、手写线程池**](#16手写线程池) 91 | - [**17、手写消费者生产者模式**](#17手写消费者生产者模式) 92 | - [**18、手写阻塞队列**](#18手写阻塞队列) 93 | - [**19、手写多线程交替打印ABC**](#19手写多线程交替打印abc) 94 | - [20、交替打印FooBar](#20交替打印foobar) 95 | - [**六、个人项目**](#六个人项目) 96 | - [**一、一站到底**](#一一站到底) 97 | - [1、如何设计排行榜](#1如何设计排行榜) 98 | - [性能优化过程](#性能优化过程) 99 | - [方案优化过程](#方案优化过程) 100 | - [方案1：每日一个滚动榜，当日汇聚（费时间）](#方案1每日一个滚动榜当日汇聚费时间) 101 | - [方案2：全局N个滚动榜同时写（费空间）](#方案2全局n个滚动榜同时写费空间) 102 | - [方案3：实时更新，常数次写操作](#方案3实时更新常数次写操作) 103 | - [2、**如何解决重复答题**](#2如何解决重复答题) 104 | - [**3、一个题目被多个人抢答**](#3一个题目被多个人抢答) 105 | - [**4、如何管理昵称重复**](#4如何管理昵称重复) 106 | - [**5、如何管理出题定时任务**](#5如何管理出题定时任务) 107 | - [**6：如何解决客户端断连**](#6如何解决客户端断连) 108 | - [二、秒杀项目](#二秒杀项目) 109 | - [**技术选型**](#技术选型) 110 | - [方案设计](#方案设计) 111 | - [**1、如何解决超卖？**](#1如何解决超卖) 112 | - [**2、如何解决重复下单？**](#2如何解决重复下单) 113 | - [**3、如何防刷？**](#3如何防刷) 114 | - [**4、热key问题如何解决？**](#4热key问题如何解决) 115 | - [**5、应对高并发的读请求**](#5应对高并发的读请求) 116 | - [**6、应对高并发的写请求**](#6应对高并发的写请求) 117 | - [**7、如何保证数据一致性**](#7如何保证数据一致性) 118 | - [8、可靠性如何保障**](#8可靠性如何保障) 119 | - [9、秒杀系统瓶颈-日志](#9秒杀系统瓶颈-日志) 120 | - [三、即时通信](#三即时通信) 121 | - [1、**单聊消息可靠传输**](#1单聊消息可靠传输) 122 | - [**2、群聊消息如何保证不丢不重**](#2群聊消息如何保证不丢不重) 123 | - [3、**如何保证消息的时序性**](#3如何保证消息的时序性) 124 | - [**4：推拉结合**](#4推拉结合) 125 | - [5、好友推荐](#5好友推荐) 126 | - [四、智慧社区](#四智慧社区) 127 | - [**物联网架构**](#物联网架构) 128 | - [DCM系统架构](#dcm系统架构) 129 | - [**三要素**](#三要素) 130 | - [云 / 边 / 端协同](#云--边--端协同) 131 | - [物联网平台接入](#物联网平台接入) 132 | - [门锁接入](#门锁接入) 133 | - [各种协议](#各种协议) 134 | - [IOT流量洪峰](#iot流量洪峰) 135 | - [社区直播带货](#社区直播带货) 136 | - [**产品的背景**](#产品的背景) 137 | - [面临的挑战](#面临的挑战) 138 | - [协议的比较](#协议的比较) 139 | - [整体流程](#整体流程) 140 | - [**直播流程**](#直播流程) 141 | - [播放流程](#播放流程) 142 | - [**直播高可用方案**](#直播高可用方案) 143 | - [**性能优化方案**](#性能优化方案) 144 | - [流量回放自动化测试](#流量回放自动化测试) 145 | - [**七、架构设计**](#七架构设计) 146 | - [1、社区系统的架构](#1社区系统的架构) 147 | - [2、商城系统-亿级商品如何存储](#2商城系统-亿级商品如何存储) 148 | - [3、对账系统-分布式事务一致性](#3对账系统-分布式事务一致性) 149 | - [4、用户系统-多线程数据割接](#4用户系统-多线程数据割接) 150 | - [5、秒杀系统场景设计](#5秒杀系统场景设计) 151 | - [**6、统计系统-海量计数**](#6统计系统-海量计数) 152 | - [7、系统设计 - 微软](#7系统设计---微软) 153 | - [**1、需求收集**](#1需求收集) 154 | - [**2、顶层设计**](#2顶层设计) 155 | - [**3、系统核心指标**](#3系统核心指标) 156 | - [4、数据存储](#4数据存储) 157 | - [7、如何设计一个微博](#7如何设计一个微博) 158 | - [八、领域模型落地](#八领域模型落地) 159 | - [1、拆分微服务](#1拆分微服务) 160 | - [2、关联微服务](#2关联微服务) 161 | - [**3、微服务的落地**](#3微服务的落地) 162 | - [4、领域模型的意义](#4领域模型的意义) 163 | - [5、战略建模](#5战略建模) 164 | - [**6、相关名词**](#6相关名词) 165 | 166 | # 一、ES篇 167 | 168 | > Elasticsearch可以实现**秒级**的搜索，cluster是一种分布式的部署，极**易扩展(scale )**这样很容易使它处理PB级的数据库容量。最重要的是Elasticsearch是它搜索的结果可以按照分数进行排序，它能提供我们最**相关**的搜索结果（**relevance**) 。 169 | 170 | ## 1、概述 171 | 172 | ### 特点 173 | 174 | 1. **安装方便**：没有其他依赖，下载后安装非常方便；只用修改几个参数就可以搭建起来一个集群 175 | 176 | 2. **JSON**：输入/输出格式为 JSON，意味着不需要定义 Schema，快捷方便 177 | 178 | 3. **RESTful**：基本所有操作 ( 索引、查询、甚至是配置 ) 都可以通过 HTTP 接口进行 179 | 180 | 4. **分布式**：节点对外表现对等（每个节点都可以用来做入口） 加入节点自动负载均衡 181 | 5. **多租户**：可根据不同的用途分索引，可以同时操作多个索引 182 | 183 | 6. **支持超大数据**： 可以扩展到 PB 级的结构化和非结构化数据 海量数据的近实时处理 184 | 185 | ### 功能 186 | 187 | - **分布式的搜索引擎** 188 | 189 | 分布式：Elasticsearch自动将海量数据分散到多台服务器上去存储和检索 190 | 191 | - **全文检索** 192 | 193 | 提供模糊搜索等自动度很高的查询方式，并进行相关性排名，高亮等功能 194 | 195 | - **数据分析引擎（分组聚合）** 196 | 197 | 社区网站，最近一周用户登录、最近一个月各功能使用情况 198 | 199 | - **对海量数据进行近实时（秒级）的处理** 200 | 201 | 海量数据的处理：因为是分布式架构，可以采用大量的服务器去存储和检索数据 202 | 203 | ### 场景 204 | 205 | - **搜索类**场景 206 | 207 | 比如说人员检索、设备检索、App内的搜索、订单搜索。 208 | 209 | - **日志分析**类场景 210 | 211 | 经典的ELK组合（**Elasticsearch**/**Logstash**/**Kibana**），实现**日志收集**，**日志存储**，**日志分析** 212 | 213 | - **数据预警平台**及数据分析场景 214 | 215 | 例如社区团购提示，当优惠的价格低于某个值时，自动触发通知消息，通知用户购买。 216 | 217 | 分析竞争对手商品销量Top10，供运营分析等等。 218 | 219 | - **商业BI(Business Intelligence)**系统 220 | 221 | 比如社区周边，需要分析某一地区用户消费金额及商品类别，输出相应的报表数据，并预测该地区的热卖商品，通过区域和人群特征划分进行定向推荐。Elasticsearch执行数据分析和挖掘，Kibana做数据可视化。 222 | 223 | ### 竞品分析 224 | 225 | **Lucene** 226 | 227 | Java编写的信息搜索工具包（Jar包），Lucene只是一个框架，熟练运用Lucene非常复杂。 228 | 229 | **Solr** 230 | 231 | 基于**Lucene**的HTTP接口查询服务器，是一个封装了很多Lucene细节搜索引擎系统 232 | 233 | **Elasticsearch** 234 | 235 | 基于**Lucene**分布式海量数据近实时搜索引擎。采用的策略是将每一个字段都编入索引，使其可以被搜索。 236 | 237 | ### 对比 238 | 239 | 1）Solr利用Zookeeper进行分布式管理，而Elasticsearch自身带有分布式协调管理功能 240 | 241 | 2）Solr比Elasticsearch实现更加全面，而Elasticsearch本身更注重于核心功能， 高级功能多由第三方插件提供 242 | 243 | 3）Solr在传统的搜索应用中表现好于Elasticsearch，而Elasticsearch在实时搜索应用方面比Solr表现好 244 | 245 | 目前主流依然是**Elasticsearch**7.x 最新的是7.8 246 | 247 | ​ 优化：**默认集成JDK**、升级Lucene8大幅提升**TopK性能**、引入熔断机制**避免OOM**发生 248 | 249 | 250 | 251 | 252 | 253 | ## 2、基本概念 254 | 255 | ### IK分词器 256 | 257 | IKAnalyzer是一个开源的，基于java语言开发的轻量级的中文分词工具包。新版本的IKAnalyzer3.0则发展为 面向Java的公用分词组件，独立于Lucene项目，同时提供了对Lucene的默认优化实现。 258 | 259 | IK分词器3.0的特性如下： 260 | 261 | 1. 采用了特有的“正向迭代**最细粒度**切分算法“，具有**60万**字/秒的高速处理能力。 262 | 2. 采用了**多子处理器**分析模式，支持：英文字母（IP地址、Email、URL）、数字（日期，常用中文数量词，罗马数字，科学计数法），中文词汇（姓名、地名处理）等分词处理。 263 | 3. 支持**个人词条的优化**的词典存储，更小的内存占用。 264 | 4. 针对Lucene**全文检索优化**的查询分析器IKQueryParser；采用歧义分析算法优化查询关键字的搜索 265 | 5. 排列组合，能极大的提高Lucene检索的命中率。 266 | 267 | - **扩展词典**：ext_dict 268 | - **停用词典**：stop_dict 269 | - **同义词典**：same_dict 270 | 271 | 272 | 273 | ### 索引（类数据库） 274 | 275 | settings：设置索引库，定义索引库的分片数副本数等 276 | 277 | ### 映射（类表设计） 278 | 279 | - 字段的数据类型 280 | - 分词器类型 281 | - 是否要进行存储或者创造索引 282 | 283 | ### 文档（数据） 284 | 285 | - 全量更新用Put 286 | - 局部更新用Post 287 | 288 | 289 | 290 | 291 | 292 | ## 3、高级特性 293 | 294 | ### 映射高级 295 | 296 | #### **地理坐标点数据类型** 297 | 298 | > 地理坐标点是指地球表面可以用经纬度描述的一个点。 地理坐标点可以用来计算两个坐标间的距离，还可以判断一个坐标是否在一个区域中。地理坐标点需要显式声明对应字段类型为 geo_point 299 | 300 | #### 动态映射 301 | 302 | > 使用dynamic mapping 来确定字段的数据类型并自动把新的字段添加到类型映射 303 | 304 | 305 | 306 | ### DSL高级 307 | 308 | - **查询所有(match_all query)** 309 | - **全文搜索(full-text query)** 310 | - 匹配搜索(match query) 311 | - 短语搜索(match phrase query) 312 | - 默认查询(query string) 313 | - 多字段匹配搜索(multi match query) 314 | 315 | - **词条级搜索(term-level query)** 316 | - 精确搜索term 317 | - 集合搜索idx 318 | - 范围搜索range 319 | - 前缀搜索prefix 320 | - 通配符搜索wildcard 321 | - 正则搜索regexp 322 | - 模糊搜索fuzzy 323 | 324 | - 复合搜索 325 | - 排序**sort**&分页**size**&高亮**highLight**&批量**bluk** 326 | 327 | 328 | 329 | ### **聚合分析** 330 | 331 | > 聚合分析是数据库中重要的功能特性，完成对一个查询的数据集中数据的聚合计算，如：找出某字段（或计算表达式的结果）的最大值、最小值，计算和、平均值等 332 | 333 | - 对一个数据集求最大、最小、和、平均值等指标的聚合，在ES中称为**指标聚合** **metric** 334 | - 对查询出的数据进行**分桶**group by，再在**桶**上进行指标**桶聚合** **bucketing** 335 | 336 | 337 | 338 | ### **智能搜索** 339 | 340 | - Term Suggester 341 | - Phrase Suggester 342 | - Completion Suggester 343 | - Context Suggester 344 | 345 | 如果**Completion Suggester**已经到了零匹配，可以猜测用户有输入错误，这时候可以尝试一下**Phrase Suggester**。如果还是未匹配则尝试**Term Suggester**。 346 | 347 | 精准程度上(**Precision**)看： **Completion > Phrase > Term**， 而召回率上(Recall)则反之。 348 | 349 | 从性能上看，Completion Suggester是最快的，如果能满足业务需求，只用Completion Suggester做前缀匹配是最理想的。 Phrase和Term由于是做倒排索引的搜索，相比较而言性能应该要低不少，应尽量控制Suggester用到的索引的数据量，最理想的状况是经过一定时间预热后，索引可以全量map到内存。 350 | 351 | 352 | 353 | 354 | 355 | ## 4、实战 356 | 357 | ### 写优化 358 | 359 | - **副本数量**0 360 | 361 | 首次 初始化数据时，将副本设置为0，写入完毕再改回，避免了副本建立索引的过程 362 | 363 | - **自动生成id** 364 | 365 | 可以避免写前判断是否存在的过程 366 | 367 | - **合理使用分词器** 368 | 369 | binary类型不适用，title和text使用不同的分词器加快速度 370 | 371 | - **禁用评分，延长索引刷新间隔** 372 | 373 | - **将多个索引操作放入到batch进行处理** 374 | 375 | 376 | 377 | ### 读优化 378 | 379 | - 使用**Filter**代替Query，减少打分缓解，使用**bool**组合query和filter查询 380 | 381 | - 对数据进行**分组**，按照日，月，年不同维度分组，查询可集中在局部index中 382 | 383 | 384 | 385 | ### 零停机索引重建方案 386 | 387 | - **外部数据导入** 388 | 389 | - 通过MQ的web控制台或cli命令行，发送指定的MQ消息 390 | - MQ消息被微服务模块的消费者消费，触发ES数据重新导入功能 391 | - 微服务模块从数据库里查询数据的总数及分页信息，并发送至MQ 392 | - 微服务从MQ中根据分页信息从数据库获取到数据后，根据索引结构的定义，将数据组装成ES支持的JSON格式，并通过bulk命令将数据发送给Elasticsearch集群进行索引的重建工作。 393 | 394 | - **基于Scroll+bulk+索引别名的方案** 395 | 396 | - 新建索引book_new，将mapping信息，settings信息等按新的要求全部定义好 397 | 398 | - 使用scroll api将数据批量查询出来，指定scroll查询持续时间 399 | 400 | - 采用bulk api将scoll查出来的一批数据，批量写入新索引 401 | 402 | - 查询一批导入一批，注意每次都使用上次结束时的scoll_id 403 | 404 | - 切换别名book_alias到新的索引book_new上面，此时Java客户端仍然使用别名访问，也不需要修 405 | 406 | 改任何代码，不需要停机。验证别名查询的是否为新索引的数据 407 | 408 | - **Reindex API方案** 409 | 410 | - Elasticsearch v6.3.1已经支持Reindex API，它对scroll、bulk做了一层封装，能够 对文档重建索引而不需要任何插件或外部工具。 411 | 412 | 413 | 414 | **参与度** & **灵活性**：自研 > scroll+bulk > reindex 415 | 416 | **稳定性** & **可靠性**：自研 < scroll+bulk < reindex 417 | 418 | 419 | 420 | ### DeepPaging性能解决方案 421 | 422 | > 比如超级管理员，要给某个省份用户发送公告或者广告，最容易想到的就是利用 from + size 来实现，但这是不现实的 423 | 424 | 425 | 426 | image-20210206212712493 427 | 428 | 429 | 430 | 431 | 432 | 433 | 434 | 435 | 436 | # 二：Docker&K8S篇 437 | 438 | > chroot 是在 Unix 和 Linux 系统的一个操作，针对正在运作的软件行程和它的子进程，改变它外显的根目录。一个运行在这个环境下，经由 chroot 设置根目录的程序，它不能够对这个指定根目录之外的文件进行访问动作，不能读取，也不能更改它的内容。 439 | 440 | **虚拟化技术_VMware 、VirtualBox、KVM** 441 | 442 | 虚拟化技术就是在操作系统上多加了一个虚拟化层（Hypervisor），可以将物理机的CPU、内存、硬盘、网络等资源进行虚拟化，再通过虚拟化出来的空间上安装操作系统，构建虚拟的应用程序执行环境。这就是我们通常说的虚拟机。 443 | 444 | 虚拟机的优点： 445 | 446 | - 提升IT效率、降低运维成本 447 | - 更快地部署工作负责 448 | - 提高服务器可用性 449 | 450 | 虚拟机的缺点： 451 | 452 | - 占用资源较多、性能较差 453 | - 扩展、迁移能力较差 454 | 455 | 456 | 457 | ### Why Docker 458 | 459 | **场景** 460 | 461 | - 开发人员在本地编写代码，并使用Docker容器与其他同事共享劳动成果。 462 | - 使用Docker将应用程序推送到测试环境中，并执行自动和手动测试。 463 | - 开发人员可以在开发环境中对其进行修复，然后将其重新部署到测试环境中以进行测试和验证。 464 | - 测试完成后，将修补程序推送给生产环境就像将更新的镜像推送到生产环境一样简单。 465 | 466 | **需求** 467 | 468 | > 快速，一致地交付应用程序、镜像打包环境，避免了环境不一致的问题，简化开发的生命周期，适合于快速迭代敏捷开发的场景 469 | 470 | image-20210220140837929 471 | 472 | 473 | 474 | ### 核心概念 475 | 476 | **Docker引擎-守护进程** 477 | 478 | ​ Docker使用C / S架构 ：用户通过**Docker客户端**与Docker守护进程（Docker引擎）通过Unix套接字或者RESTAPI进行通信，**Docker引擎**完成了构建，运行和分发Docker容器的繁重工作 479 | 480 | 481 | 482 | **Docker镜像-Dockerfile** 483 | 484 | ​ Docker镜像类似于虚拟机镜像，是一个只读的模板，是创建Docker容器的基础 485 | 486 | ​ 镜像是基于联合（Union）文件系统的一种层式的结构，由一系列指令一步一步构建出来。 487 | 488 | ​ 比如：拷贝文件、执行命令 489 | 490 | 491 | 492 | **Docker仓库-Hub** 493 | 494 | Docker仓库可以分为**公开仓库 （Public）**和**私有仓库（Private）**两种形式。 495 | 496 | 最大的公开仓库是官方提供的**Docker Hub**，其中存放了数量庞大的镜像供用户下载。 497 | 498 | 499 | 500 | ### 基本操作 501 | 502 | **镜像** 503 | 504 | ```dockerfile 505 | [root@localhost ~]# docker pull mysql:5.7.30 506 | 5.7.30: Pulling from library/mysql …… 507 | [root@localhost ~]# docker images 508 | REPOSITORY TAG IMAGE ID CREATED SIZE 509 | mysql 5.7.30 9cfcce23593a 6 weeks ago 448MB 510 | [root@localhost ~]# docker tag mysql:5.7.30 mysql5 511 | [root@localhost ~]# docker images 512 | REPOSITORY TAG IMAGE ID CREATED SIZE 513 | mysql5 latest 9cfcce23593a 6 weeks ago 448MB 514 | mysql 5.7.30 9cfcce23593a 6 weeks ago 448MB 515 | [root@localhost ~]# docker inspect mysql:5.7.30 516 | [{显示docker 详细信息}] 517 | [root@localhost ~]# docker search mysql 518 | [root@localhost ~]# docker rmi mysql:5.7.30 519 | [root@localhost ~]# docker push mysql[:TAG] 520 | ``` 521 | 522 | **容器** 523 | 524 | ```dockerfile 525 | [root@localhost ~]# docker create -it nginx 526 | [root@localhost ~]# docker start 9cfcce23593a 527 | 528 | #查看运行的容器 529 | [root@localhost ~]# docker ps 530 | #查看所有容器 531 | [root@localhost ~]# docker ps -a 532 | #新建并启动容器 533 | [root@localhost ~]# docker run -it --rm --network host tomcat:8.5.56-jdk8-openjdk 534 | ``` 535 | 536 | 537 | 538 | ### 实战 539 | 540 | 1. 创建一个卷，待后边使用 541 | 542 | ```dockerfile 543 | docker volume create test_volume 544 | ``` 545 | 546 | 547 | 548 | 2. 分别启动2个容器挂在上卷, 549 | 550 | ```dockerfile 551 | 在2个终端窗口启动2个容器 552 | docker run -it --rm -v test_volume:/test nginx:latest /bin/bash 553 | docker run -it --rm -v test_volume:/test nginx:latest /bin/bash 554 | cd /test; 555 | touch a.txt 556 | ls /test # 在两个容器中我们均可以看到我们创建的文件，shixian在多个容器之间实现数据共享 557 | ``` 558 | 559 | 560 | 561 | 挂载在容器 /test 目录内创建。 Docker **不支持容器内安装点的相对路径**。 多个容器可以在同一时间段内使用相同的卷。如果两个容器需要访问共享数据，例如，如果一个容器写入而另一个容器读取数据。 卷名 在驱动程序test必须唯一。这意味着不能将**相同的卷名**与两个不同的驱动程序一起使用。 如果我们指定了当前test_volume程序上已在使用的卷名，则Docker会假定我们要重用现有卷，并且不会返回错误。如果开始无 test_volume 则会创建这个卷当然除了使用卷，也可以使用将宿主机的文件映射到容器的卷，命令类似，只不过不用提前创建卷，而且数据会映射到宿主机上注意如果宿主机上的目录可以不存在，会在启动容器的时候创建 562 | 563 | 564 | 565 | # 三、Netty篇 566 | 567 | ### 核心组件 568 | 569 | #### 1、整体结构 570 | 571 | image-20210504171606057 572 | 573 | ​ 574 | 575 | ​ **Core 核心层** 576 | ​ Core 核心层是 Netty 最精华的内容，它提供了底层网络通信的通用抽象和实现，包括事件模型、通用API、支持零拷贝的 ByteBuf 等。 577 | 578 | ​ **Protocol Support 协议支持层** 579 | ​ 协议支持层基本上覆盖了主流协议的编解码实现，如 HTTP、Protobuf、WebSocket、二进制等主流协议，此外 Netty 还支持自定义应用层协议。Netty 丰富的协议支持降低了用户的开发成本，基于 Netty 我们可以快速开发 HTTP、WebSocket 等服务。 580 | 581 | ​ **Transport Service 传输服务层** 582 | ​ 传输服务层提供了网络传输能力的定义和实现方法。它支持 Socket、HTTP 隧道、虚拟机管道等传输方式。Netty 对 TCP、UDP 等数据传输做了抽象和封装，用户可以更聚焦在业务逻辑实现上，而不必关系底层数据传输的细节。 583 | 584 | 585 | 586 | #### 2、逻辑架构 587 | 588 | image-20210504171514089 589 | 590 | ​ 591 | 592 | ​ **网络通信层** 593 | ​ 网络通信层的职责是执行网络 I/O 的操作。它支持多种网络协议和 I/O 模型的连接操作。当网络数据读取到内核缓冲区后，会触发各种网络事件，这些网络事件会分发给事件调度层进行处理。 594 | 595 | 网络通信层的核心组件包含**BootStrap、ServerBootStrap、Channel**三个组件。 596 | 597 | ​ Bootstrap 是“引导”的意思，负责 Netty **客户端程序**的启动、初始化、服务器连接等过程，串联了 Netty 的其他核心组件。 598 | 599 | ​ ServerBootStrap 用于**服务端启动**绑定本地端口，会绑定Boss 和 Worker两个 EventLoopGroup。 600 | 601 | ​ Channel 的是“**通道**”，Netty Channel提供了基于NIO更高层次的抽象，如 register、bind、connect、read、write、flush 等。 602 | 603 | ​ 604 | 605 | ​ **事件调度层** 606 | ​ 事件调度层的职责是通过 Reactor 线程模型对各类事件进行聚合处理，通过 Selector 主循环线程集成多种事件（ I/O 事件、信号事件、定时事件等），实际的业务处理逻辑是交由服务编排层中相关的 Handler 完成。 607 | 608 | 事件调度层的核心组件包括 **EventLoopGroup、EventLoop**。 609 | 610 | image-20210504171631793 611 | 612 | ​ 613 | 614 | ​ **EventLoop** 负责处理 Channel 生命周期内的所有 I/O 事件，如 accept、connect、read、write 等 I/O 事件 615 | 616 | ​ ①一个 EventLoopGroup 往往包含**一个或者多个** EventLoop。 617 | 618 | ​ ②EventLoop 同一时间会与一个Channel绑定，每个 EventLoop 负责**处理一种类型 Channel**。 619 | 620 | ​ ③Channel 在生命周期内可以对和多个 EventLoop 进行**多次绑定和解绑**。 621 | 622 | ​ **EventLoopGroup** 是Netty 的**核心处理引擎**，本质是一个线程池，主要负责接收 I/O 请求，并分配线程执行处理请求。通过创建不同的 EventLoopGroup 参数配置，就可以支持 Reactor 的三种线程模型： 623 | 624 | ​ **单线程模型**：EventLoopGroup 只包含一个 EventLoop，Boss 和 Worker 使用同一个EventLoopGroup； 625 | 626 | ​ **多线程模型**：EventLoopGroup 包含多个 EventLoop，Boss 和 Worker 使用同一个EventLoopGroup； 627 | 628 | ​ **主从多线程模型**：EventLoopGroup 包含多个 EventLoop，Boss 是主 Reactor，Worker 是从 Reactor，它们分别使用不同的 EventLoopGroup，主 Reactor 负责新的网络连接 Channel 创建，然后把 Channel 注册到从 Reactor。 629 | 630 | 631 | 632 | ​ **服务编排层** 633 | ​ 服务编排层的职责是负责组装各类服务，它是 Netty 的核心处理链，用以实现网络事件的动态编排和有序传播。 634 | 635 | 服务编排层的核心组件包括 **ChannelPipeline、ChannelHandler、ChannelHandlerContext**。 636 | 637 | ​ **ChannelPipeline** 是 Netty 的核心编排组件，负责组装各种 ChannelHandler，ChannelPipeline 内部通过双向链表将不同的 ChannelHandler 链接在一起。当 I/O 读写事件触发时，Pipeline 会依次调用 Handler 列表对 Channel 的数据进行拦截和处理。 638 | 639 | image-20210504171749533 640 | 641 | ​ 642 | 643 | ​ 客户端和服务端都有各自的 ChannelPipeline。客户端和服务端一次完整的请求：客户端出站（Encoder 请求数据）、服务端入站（Decoder接收数据并执行业务逻辑）、服务端出站（Encoder响应结果）。 644 | 645 | 646 | 647 | ​ **ChannelHandler** 完成数据的编解码以及处理工作。 648 | 649 | image-20210504171829071 650 | 651 | 652 | 653 | ​ **ChannelHandlerContext** 用于保存Handler 上下文，通过 HandlerContext 我们可以知道 Pipeline 和 Handler 的关联关系。HandlerContext 可以实现 Handler 之间的交互，HandlerContext 包含了 Handler 生命周期的所有事件，如 connect、bind、read、flush、write、close 等。同时，HandlerContext 实现了Handler通用的逻辑的模型抽象。 654 | 655 | image-20210504171924019 656 | 657 | 658 | 659 | 660 | 661 | ### 网络传输 662 | 663 | #### **1、五种IO模型的区别** 664 | 665 | **阻塞I/O：（BIO）** 666 | 667 | image-20210504171959821 668 | 669 | ​ 670 | 671 | ​ 应用进程向内核发起 I/O 请求，发起调用的线程一直等待内核返回结果。一次完整的 I/O 请求称为BIO（Blocking IO，阻塞 I/O），所以 BIO 在实现异步操作时，只能使用多线程模型，一个请求对应一个线程。但是，**线程的资源是有限且宝贵的，创建过多的线程会增加线程切换的开销。** 672 | 673 | **同步非阻塞I/O（NIO）：** 674 | 675 | image-20210504172029418 676 | 677 | ​ 678 | 679 | ​ 应用进程向内核发起 I/O 请求后不再会同步等待结果，而是会立即返回，通过轮询的方式获取请求结果。NIO 相比 BIO 虽然大幅提升了性能，但是轮询过程中大量的系统调用导致上下文切换开销很大。所以，单独使用非阻塞 I/O 时效率并不高，而且**随着并发量的提升，非阻塞 I/O 会存在严重的性能浪费。** 680 | 681 | **多路复用I/O（select和poll）：** 682 | 683 | image-20210504172057237 684 | 685 | ​ 686 | 687 | ​ 多路复用实现了**一个线程处理多个 I/O 句柄的操作**。多路指的是多个数据通道，复用指的是使用一个或多个固定线程来处理每一个 Socket。select、poll、epoll 都是 I/O 多路复用的具体实现，线程一次 select 调用可以获取内核态中多个数据通道的数据状态。其中，select只负责等，recvfrom只负责拷贝，阻塞IO中可以对多个文件描述符进行阻塞监听，是一种非常高效的 I/O 模型。 688 | 689 | **信号驱动I/O（SIGIO）：** 690 | 691 | image-20210504172124965 692 | 693 | ​ 694 | 695 | ​ 信号驱动IO模型，应用进程告诉内核：当数据报准备好的时候，给我发送一个信号，对SIGIO信号进行捕捉，并且调用我的信号处理函数来获取数据报。 696 | 697 | **异步I/O（Posix.1的aio_系列函数）：** 698 | 699 | ​ image-20210504172148095 700 | 701 | ​ 当应用程序调用aio_read时，内核一方面去取数据报内容返回，另一方面将程序控制权还给应用进程，应用进程继续处理其他事情，是一种非阻塞的状态。当内核中有数据报就绪时，由内核将数据报拷贝到应用程序中，返回aio_read中定义好的函数处理程序。 702 | 703 | 704 | 705 | #### 2、Reactor多线程模型 706 | 707 | ​ Netty 的 I/O 模型是基于**非阻塞 I/O** 实现的，底层依赖的是 NIO 框架的**多路复用器 Selector**。采用 **epoll 模式**后，只需要一个线程负责 Selector 的轮询。当有数据处于就绪状态后，需要一个**事件分发器**（Event Dispather），它负责将读写事件分发给对应的读写**事件处理器**（Event Handler）。事件分发器有两种设计模式：**Reactor 和 Proactor**，Reactor 采用同步 I/O， Proactor 采用异步 I/O。 708 | 709 | ​ 710 | 711 | image-20210504172207142 712 | 713 | 714 | 715 | ​ Reactor 实现相对简单，适合处理耗时短的场景，对于耗时长的 I/O 操作容易造成阻塞。Proactor 性能更高，但是实现逻辑非常复杂，适合图片或视频流分析服务器，目前主流的事件驱动模型还是依赖 **select 或 epoll** 来实现。 716 | 717 | 718 | 719 | #### 3、拆包粘包问题 720 | 721 | **拆包**TCP 传输协议是面向流的，没有数据包界限。 722 | **MTU（Maxitum Transmission Unit）** 是链路层一次最大传输数据的大小。MTU 一般来说大小为 1500 byte。**MSS（Maximum Segement Size）** 是指 TCP 最大报文段长度，它是传输层一次发送最大数据的大小。 723 | 724 | 725 | 726 | image-20210504172233844 727 | 728 | 如上图所示，如果 MSS + TCP 首部 + IP 首部 > MTU，那么数据包将会被拆分为多个发送。这就是**拆包现象**。 729 | 730 | **Nagle 算法** 731 | Nagle 算法可以理解为批量发送，也是我们平时编程中经常用到的优化思路，它是在数据未得到确认之前先写入缓冲区，等待数据确认或者缓冲区积攒到一定大小再把数据包发送出去。Netty 中为了使数据**传输延迟最小化**，就默认**禁用了 Nagle 算法**。 732 | 733 | **拆包/粘包的解决方案** 734 | 735 | 在客户端和服务端通信的过程中，服务端一次读到的数据大小是不确定的。需要确定边界： 736 | 737 | **消息长度固定** 738 | **特定分隔符** 739 | **消息长度 + 消息内容**(Netty) 740 | 741 | 742 | 743 | #### 4、自定义协议 744 | 745 | Netty 常用编码器类型： 746 | 747 | ```java 748 | MessageToByteEncoder //对象编码成字节流； 749 | 750 | MessageToMessageEncoder //一种消息类型编码成另外一种消息类型。 751 | ``` 752 | 753 | Netty 常用解码器类型： 754 | 755 | ```java 756 | ByteToMessageDecoder/ReplayingDecoder //将字节流解码为消息对象； 757 | 758 | MessageToMessageDecoder //将一种消息类型解码为另外一种消息类型。 759 | ``` 760 | 761 | 编解码器可以分为**一次解码器**和**二次解码器**，一次解码器用于解决 **TCP 拆包/粘包问题**，按协议解析后得到的字节数据。如果你需要对解析后的**字节数据做对象模型**的转换，这时候便需要用到二次解码器，同理编码器的过程是反过来的。 762 | 763 | **Netty自定义协议内容：** 764 | 765 | ```java 766 | /* 767 | +---------------------------------------------------------------+ 768 | | 魔数 2byte | 协议版本号 1byte | 序列化算法 1byte | 报文类型 1byte  | 769 | +---------------------------------------------------------------+ 770 | | 状态 1byte |        保留字段 4byte     |      数据长度 4byte     |  771 | +---------------------------------------------------------------+ 772 | |                   数据内容 （长度不定）                          | 773 | +---------------------------------------------------------------+ 774 |  */ 775 | ``` 776 | 777 | 如何判断 ByteBuf 是否存在完整的报文？最常用的做法就是通过读取消息长度 dataLength 进行判断。如果 ByteBuf 的可读数据长度小于 dataLength，说明 ByteBuf 还不够获取一个完整的报文。 778 | 779 | 780 | 781 | #### 5、WriteAndFlush 782 | 783 | ​ image-20210504172303465 784 | 785 | ​ ①writeAndFlush 属于出站操作，它是从 Pipeline 的 Tail 节点开始进行事件传播，一直向前传播到 Head 节点。不管在 write 还是 flush 过程，Head 节点都中扮演着重要的角色。 786 | 787 | ​ ②write 方法并没有将数据写入 Socket 缓冲区，只是将数据写入到 ChannelOutboundBuffer 缓存中，ChannelOutboundBuffer 缓存内部是由单向链表实现的。 788 | 789 | ​ ③flush 方法才最终将数据写入到 Socket 缓冲区。 790 | 791 | 792 | 793 | ### 内存管理 794 | 795 | #### 1、堆外内存 796 | 797 | ​ 在 Java 中对象都是在堆内分配的，通常我们说的**JVM 内存**也就指的**堆内内存**，**堆内内存**完全被**JVM 虚拟机**所管理，JVM 有自己的垃圾回收算法，对于使用者来说不必关心对象的内存如何回收。**堆外内存**与堆内内存相对应，对于整个机器内存而言，除**堆内内存以外部分即为堆外内存**。堆外内存不受 JVM 虚拟机管理，直接由操作系统管理。使用堆外内存有如下几个优点： 798 | 799 | 1. 堆内内存由 JVM GC 自动回收内存，降低了 Java 用户的使用心智，堆外内存由于不受 JVM 管理，所以在一定程度上可以降低 GC 对应用运行时带来的影响。 800 | 2. 堆外内存需要手动释放，这一点跟 C/C++ 很像，稍有不慎就会造成应用程序内存泄漏，当出现内存泄漏问题时排查起来会相对困难。 801 | 3. 当进行网络 I/O 操作、文件读写时，堆内内存都需要转换为堆外内存，然后再与底层设备进行交互，所以直接使用堆外内存可以减少一次内存拷贝。 802 | 4. 堆外内存可以方便实现进程之间、JVM 多实例之间的数据共享。 803 | 804 | ​ 在堆内存放的 DirectByteBuffer 对象并不大，仅仅包含堆外内存的地址、大小等属性，同时还会创建对应的 Cleaner 对象，通过 ByteBuffer 分配的堆外内存不需要手动回收，它可以被 JVM 自动回收。当堆内的 DirectByteBuffer 对象被 GC 回收时，Cleaner 就会用于回收对应的堆外内存。 805 | 806 | image-20210504172324820 807 | 808 | ​ 从 DirectByteBuffer 的构造函数中可以看出，真正分配堆外内存的逻辑还是通过 unsafe.allocateMemory(size)，Unsafe 是一个非常不安全的类，它用于执行内存访问、分配、修改等**敏感操作**，可以越过 JVM 限制的枷锁。Unsafe 最初并不是为开发者设计的，使用它时虽然可以获取对底层资源的控制权，但也失去了安全性的保证，使用 Unsafe 一定要慎重（Java 中是不能直接使用 Unsafe 的，但是可以通过反射获取 Unsafe 实例）。Netty 中依赖了 Unsafe 工具类，是因为 Netty 需要与底层 Socket 进行交互，Unsafe 提升 Netty 的性能 809 | 810 | ​ 因为DirectByteBuffer 对象的回收需要依赖 Old GC 或者 Full GC 才能触发清理，如果长时间没有 GC执行，那么堆外内存即使不再使用，也会一直在占用内存不释放，很容易将机器的物理内存耗尽。-XX:MaxDirectMemorySize 指定堆外内存的上限大小，超出时触发GC，仍无法释放抛出OOM异常。 811 | 812 | image-20210504172324820 813 | 814 | ​ 当初始化堆外内存时，内存中的对象引用情况如下图所示，first 是 Cleaner 类中的静态变量，Cleaner 对象在初始化时会加入 Cleaner 链表中。DirectByteBuffer 对象包含堆外内存的地址、大小以及 Cleaner 对象的引用，ReferenceQueue 用于保存需要回收的 Cleaner 对象。 815 | 816 | ​ 817 | 818 | #### 2、**数据载体ByteBuf** 819 | 820 | JDK NIO 的 **ByteBuffer** 821 | 822 | - mark：为某个读取过的关键位置做标记，方便回退到该位置； 823 | - position：当前读取的位置； 824 | - limit：buffer 中有效的数据长度大小； 825 | - capacity：初始化时的空间容量。 826 | 827 | image-20210504172358702 828 | 829 | ​ 第一，ByteBuffer 分配的长度是固定的，无法动态扩缩容，每次在存放数据的时候对容量大小做校验，扩容需要将已有的数据迁移。 830 | 831 | ​ 第二，ByteBuffer 只能通过 position 获取当前可操作的位置，因为读写共用的 position 指针，所以需要频繁调用 flip、rewind 方法切换读写状态。 832 | 833 | Netty中的ByteBuf 834 | 835 | - **废弃字节**，表示已经丢弃的无效字节数据。 836 | - **可读字节**，表示 ByteBuf 中可以被读取的字节内容，可以通过 writeIndex - readerIndex 计算得出。当读写位置重叠时时，表示 ByteBuf 已经不可读。 837 | - **可写字节**，向 ByteBuf 中写入数据都会存储到可写字节区域。当 writeIndex 超过 capacity，表示 ByteBuf 容量不足，需要扩容。 838 | - **可扩容字节**，表示 ByteBuf 最多还可以扩容多少字节，最多扩容到 maxCapacity 为止，超过 maxCapacity 再写入就会出错。 839 | 840 | image-20210504173347000 841 | 842 | **引用计数** 843 | 844 | ​ 当byteBuf当引用计数为 0，该 ByteBuf 可以被放入到对象池中，避免每次使用 ByteBuf 都重复创建。 845 | 846 | ​ JVM 并不知道 Netty 的引用计数是如何实现的，当 ByteBuf 对象不可达时，一样会被 GC 回收掉，但是如果此时 ByteBuf 的引用计数不为 0，那么该对象就不会释放或者被放入对象池，从而发生了内存泄漏。Netty 会对分配的 ByteBuf 进行抽样分析，检测 ByteBuf 是否已经不可达且引用计数大于 0，判定内存泄漏的位置并输出到日志中，**通过关注日志中 LEAK 关键字可以找到内存泄漏的具体对象**。 847 | 848 | 849 | 850 | #### 3、**内存分配jemalloc** 851 | 852 | ​ 为了减少分配时产生的内部碎片和外部碎片，常见的内存分配算法**动态内存分配**、**伙伴算法**和**Slab 算法** 853 | 854 | **动态内存分配（DMA）** 855 | 856 | ​ **⾸次适应算法（first fit）**，空闲分区链以地址递增的顺序将空闲分区以双向链表的形式连接在一起，从空闲分区链中找到第一个满足分配条件的空闲分区，然后从空闲分区中划分出一块可用内存给请求进程，剩余的空闲分区仍然保留在空闲分区链中。 857 | 858 | image-20210504173407923 859 | 860 | ​ **循环首次适应算法（next fit）**不再是每次从链表的开始进行查找，而是从上次找到的空闲分区的以后开始查找。查找效率提升，会产生更多的碎片。 861 | 862 | ​ **最佳适应算法（best fit）**，空闲分区链以空闲分区大小递增的顺序将空闲分区以双向链表的形式连接在一起，每次从空闲分区链的开头进行查找。 863 | 864 | **伙伴算法**（外部碎片少，内部碎片多） 865 | 866 | ​ 是一种非常经典的内存分配算法，它采用了**分离适配的设计思想**，将物理内存按照 2 的次幂进行划分，内存分配时也是按照 2 的次幂大小进行按需分配 867 | 868 | image-20210504173433749 869 | 870 | 1. 首先需要找到存储 2^4 连续 Page 所对应的链表，即数组下标为 4； 871 | 2. 查找 2^4 链表中是否有空闲的内存块，如果有则分配成功； 872 | 3. 如果 2^4 链表不存在空闲的内存块，则继续沿数组向上查找，即定位到数组下标为 5 的链表，链表中每个节点存储 2^5 的连续 Page； 873 | 4. 如果 2^5 链表中存在空闲的内存块，则取出该内存块并将它分割为 2 个 2^4 大小的内存块，其中一块分配给进程使用，剩余的一块链接到 2^4 链表中。 874 | 875 | **Slab 算法（解决伙伴算法内部碎片问题）** 876 | 877 | ​ Slab 算法在伙伴算法的基础上，对小内存的场景专门做了优化，采用了内存池的方案，解决内部碎片问题。 878 | 879 | image-20210504173454562 880 | 881 | 在 Slab 算法中维护着大小不同的 Slab 集合，将这块内存划分为大小相同的 slot，不会对内存块再进行合并，同时使用位图 bitmap 记录每个 slot 的使用情况。 882 | 883 | ​ kmem_cache 中包含三个 Slab 链表：**完全分配使用 slab_full**、**部分分配使用 slab_partial**和**完全空闲 slabs_empty**，这三个链表负责内存的分配和释放。Slab 算法是基于对象进行内存管理的，它把相同类型的对象分为一类。当分配内存时，从 Slab 链表中划分相应的内存单元；单个 Slab 可以在不同的链表之间移动，例如当一个 Slab 被分配完，就会从 slab_partial 移动到 slabs_full，当一个 Slab 中有对象被释放后，就会从 slab_full 再次回到 slab_partial，所有对象都被释放完的话，就会从 slab_partial 移动到 slab_empty。当**释放内存时，Slab 算法并不会丢弃已经分配的对象，而是将它保存在缓存中，当下次再为对象分配内存时，直接会使用最近释放的内存块**。 884 | 885 | 886 | 887 | #### 4、jemalloc 架构 888 | 889 | - 内存是由一定数量的 arenas 负责管理，线程均匀分布在 arenas 当中； 890 | - 每个 arena 都包含一个 bin 数组，每个 bin 管理不同档位的内存块； 891 | - 每个 arena 被划分为若干个 chunks，每个 chunk 又包含若干个 runs，每个 run 由连续的 Page 组成，run 才是实际分配内存的操作对象； 892 | - 每个 run 会被划分为一定数量的 regions，在小内存的分配场景，region 相当于用户内存； 893 | - 每个 tcache 对应一个 arena，tcache 中包含多种类型的 bin。 894 | 895 | image-20210504173454562 896 | 897 | **内存管理Arena** ，内存由一定数量的 arenas 负责管理。每个用户线程采用 round-robin 轮询的方式选择可用的 arena 进行内存分配。 898 | 899 | **分级管理Bin**，每个 bin 管理的内存大小是按分类依次递增。**jemalloc 中小内存的分配是基于 Slab 算法**完成的，会产生不同类别的内存块。 900 | 901 | **Page集合chunk**，chunk 以 Page 为单位管理内存。每个 chunk 可被用于多次小内存的申请，但是在大内存分配的场景下只能分配一次。 902 | 903 | **实际分配单位run**，run 结构具体的大小由不同的 bin 决定，例如 8 字节的 bin 对应的 run 只有一个 Page，可以从中选取 8 字节的块进行分配。 904 | 905 | **run 细分region**，每个 run 会将划分为若干个等长的 region，每次内存分配也是按照 region 进行分发。 906 | 907 | **tcache 是每个线程私有的缓存**，tcache 每次从 arena 申请一批内存，在分配内存时首先在 tcache 查找，避免锁竞争，分配失败才会通过 run 执行内存分配。 908 | 909 | ![image-20211205121406792](https://tva1.sinaimg.cn/large/008i3skNly1gx2u1jn9b3j31e80hqjt5.jpg) 910 | 911 | Small 场景，如果请求分配内存的大小小于 arena 中的最小的 bin，那么优先从线程中对应的 tcache 中进行分配。首先确定查找对应的 tbin 中是否存在缓存的内存块，如果存在则分配成功，否则找到 tbin 对应的 arena，从 arena 中对应的 bin 中分配 region 保存在 tbin 的 avail 数组中，最终从 availl 数组中选取一个地址进行内存分配，当内存释放时也会将被回收的内存块进行缓存。 912 | 913 | Large 场景的内存分配与 Smalll 类似，如果请求分配内存的大小大于 arena 中的最小的 bin，但是不大于 tcache 中能够缓存的最大块，依然会通过 tcache 进行分配，但是不同的是此时会分配 chunk 以及所对应的 run，从 chunk 中找到相应的内存空间进行分配。内存释放时也跟 samll 场景类似，会把释放的内存块缓存在 tacache 的 tbin 中。此外还有一种情况，当请求分配内存的大小大于tcache 中能够缓存的最大块，但是不大于 chunk 的大小，那么将不会采用 tcache 机制，直接在 chunk 中进行内存分配。 914 | 915 | Huge 场景，如果请求分配内存的大小大于 chunk 的大小，那么直接通过 mmap 进行分配，调用 munmap 进行回收。 916 | 917 | 918 | 919 | #### 5、内存池设计（待补充） 920 | 921 | #### 6、Recycle对象池（待补充） 922 | 923 | #### 7、零拷贝技术 924 | 925 | 1. 当用户进程发起 read() 调用后，上下文从用户态切换至内核态。DMA 引擎从文件中读取数据，并存储到内核态缓冲区，这里是**第一次数据拷贝**。 926 | 2. 请求的数据从内核态缓冲区拷贝到用户态缓冲区，然后返回给用户进程。**第二次数据拷贝**的过程同时，会导致上下文从内核态再次切换到用户态。 927 | 3. 用户进程调用 send() 方法期望将数据发送到网络中，用户态会再次切换到内核态，**第三次数据拷贝**请求的数据从用户态缓冲区被拷贝到 Socket 缓冲区。 928 | 4. 最终 send() 系统调用结束返回给用户进程，发生了第四次上下文切换。**第四次拷贝会异步执行**，从 Socket 缓冲区拷贝到协议引擎中。 929 | 930 | image-20210504175240348 931 | 932 | ​ **在 Linux 中**系统调用 sendfile() 可以实现将数据从一个文件描述符传输到另一个文件描述符，从而实现了零拷贝技术。 933 | 934 | ​ **在 Java 中**也使用了零拷贝技术，它就是 NIO FileChannel 类中的 transferTo() 方法，它可以将数据从 FileChannel 直接传输到另外一个 Channel。 935 | 936 | image-20210504175323875 937 | 938 | **Netty 中的零拷贝**技术除了操作系统级别的功能封装，更多的是面向用户态的数据操作优化，主要体现在以下 5 个方面： 939 | 940 | - 堆外内存，避免 JVM 堆内存到堆外内存的数据拷贝。 941 | - CompositeByteBuf 类，可以组合多个 Buffer 对象合并成一个逻辑上的对象，避免通过传统内存拷贝的方式将几个 Buffer 合并成一个大的 Buffer。 942 | - 通过 Unpooled.wrappedBuffer 可以将 byte 数组包装成 ByteBuf 对象，包装过程中不会产生内存拷贝。 943 | - ByteBuf.slice ，slice 操作可以将一个 ByteBuf 对象切分成多个 ByteBuf 对象，切分过程中不会产生内存拷贝，底层共享一个 byte 数组的存储空间。 944 | - Netty 使用 封装了transferTo() 方法 FileRegion，可以将文件缓冲区的数据直接传输到目标 Channel，避免内核缓冲区和用户态缓冲区之间的数据拷贝。 945 | 946 | 947 | 948 | ### 高性能数据结构 949 | 950 | #### 1、FastThreadLocal 951 | 952 | ​ ThreadLocal 可以理解为线程本地变量。ThreadLocal 为变量在每个线程中都创建了一个副本，该副本只能被当前线程访问，多线程之间是隔离的，变量不能在多线程之间共享。这样每个线程修改变量副本时，不会对其他线程产生影响。 953 | 954 | ​ 既然多线程访问 ThreadLocal 变量时都会有自己独立的实例副本，那么很容易想到的方案就是在 ThreadLocal 中维护一个 Map，记录线程与实例之间的映射关系。当新增线程和销毁线程时都需要更新 Map 中的映射关系，因为会存在多线程并发修改，所以需要保证 Map 是线程安全的。但是在高并发的场景并发修改 Map 需要加锁，势必会降低性能。 955 | 956 | image-20210504175349901 957 | 958 | ​ JDK 为了避免加锁，采用了相反的设计思路。以 Thread 入手，在 Thread 中维护一个 Map，记录 ThreadLocal 与实例之间的映射关系，这样在同一个线程内，Map 就不需要加锁了。 959 | 960 | image-20210504175406824 961 | 962 | ​ ThreadLocalMap 是一种使用线性探测法实现的哈希表，底层采用数组存储数据，通过魔数0x61c88647来使散列更加平衡。ThreadLocalMap 初始化一个长度为 16 的 Entry 数组。与 HashMap 不同的是，Entry 的 key 就是 ThreadLocal对象本身，value 就是用户具体需要存储的值。 963 | 964 | image-20210504175428964 965 | 966 | ​ Entry 继承自弱引用类 WeakReference，Entry 的 key 是弱引用，value 是强引用。在 JVM 垃圾回收时，只要发现了弱引用的对象，不管内存是否充足，都会被回收。那么为什么 Entry 的 key 要设计成弱引用呢？如果 key 都是强引用，当线 ThreadLocal 不再使用时，然而 ThreadLocalMap 中还是存在对 ThreadLocal 的强引用，那么 GC 是无法回收的，从而造成内存泄漏。 967 | 968 | img 969 | 970 | ​ 虽然 Entry 的 key 设计成了弱引用，但是当 ThreadLocal不再使用(**业务逻辑走完，但是由于线程复用导致线程并没有结束**)被 GC 回收后，ThreadLocalMap 中可能出现 Entry 的 key 为 NULL，那么 Entry 的 value 一直会强引用数据而得不到释放，只能等待线程销毁。那么应该如何避免 ThreadLocalMap 内存泄漏呢？ThreadLocal 已经帮助我们做了一定的保护措施，在执行 ThreadLocal.set()/get() 方法时，ThreadLocal 会清除 ThreadLocalMap 中 key 为 NULL 的 Entry 对象，让它还能够被 GC 回收。除此之外，当线程中某个 ThreadLocal 对象不再使用时，立即调用 remove() 方法删除 Entry 对象。如果是在异常的场景中，应在 finally 代码块中进行清理，保持良好的编码意识。在Netty中，可以方便的使用FashThreadLocal来防止内存泄漏 971 | 972 | img 973 | 974 | **FastThreadLocal** 975 | 976 | ​ FastThreadLocal 使用 Object 数组替代了 Entry 数组，Object[0] 存储的是一个Set> 集合，从数组下标 1 开始都是直接存储的 value 数据，不再采用 ThreadLocal 的键值对形式进行存储。主要是针对set方法，增加了两个额外的行为。 977 | 978 | 1. 找到数组下标 index 位置，设置新的 value。 979 | 2. 将 **FastThreadLocal 对象保存到待清理的 Set 中**。 980 | 981 | image-20210504175457264 982 | 983 | - **高效查找**。FastThreadLocal 在定位数据的时候可以直接根据数组下标 index 获取，时间复杂度 O(1)。而 JDK 原生的 ThreadLocal 在数据较多时哈希表很容易发生 Hash 冲突，线性探测法在解决 Hash 冲突时需要不停地向下寻找，效率较低。此外，FastThreadLocal 相比 ThreadLocal 数据扩容更加简单高效，FastThreadLocal 以 index 为基准向上取整到 2 的次幂作为扩容后容量，然后把原数据拷贝到新数组。而 ThreadLocal 由于采用的哈希表，所以在扩容后需要再做一轮 rehash。 984 | - **安全性更高**。JDK 原生的 ThreadLocal 使用不当可能造成内存泄漏，只能等待线程销毁。在使用线程池的场景下，ThreadLocal 只能通过主动检测的方式防止内存泄漏，从而造成了一定的开销。然而 FastThreadLocal 不仅提供了 remove() 主动清除对象的方法，而且在线程池场景中 Netty 还封装了 FastThreadLocalRunnable，**任务执行完毕后一定会执行 FastThreadLocal.removeAll() 将 Set 集合中所有 FastThreadLocal 对象都清理掉** 985 | 986 | 987 | 988 | 989 | 990 | #### 2、**HashedTimerWheel** 991 | 992 | ​ 生成月统计报表、每日得分结算、邮件定时推送 993 | 994 | ​ 定时任务三种形式： 995 | 996 | ​ 1、按固定周期定时执行 997 | 998 | ​ 2、延迟一定时间后执行 999 | 1000 | ​ 3、指定某个时刻执行 1001 | 1002 | ​ 定时任务的三个关键方法： 1003 | 1004 | ​ Schedule 新增任务至任务集合； 1005 | 1006 | ​ Cancel 取消某个任务； 1007 | 1008 | ​ Run 执行到期的任务 1009 | 1010 | JDK自带的三种定时器：**Timer**、**DelayedQueue** 和 **ScheduledThreadPoolExecutor** 1011 | 1012 | Timer小根堆队列，deadline 任务位于堆顶端，弹出的始终是最优先被执行的任务。Run 操作时间复杂度 O(1)，Schedule 和Cancel 操作的时间复杂度都是 O(logn)。 1013 | 1014 | 不论有多少任务被加入数组，始终由 异步线程TimerThread 负责处理。TimerThread 会定时轮询 TaskQueue 中的任务，如果堆顶的任务的 deadline 已到，那么执行任务；如果是周期性任务，执行完成后重新计算下一次任务的 deadline，并再次放入小根堆；如果是单次执行的任务，执行结束后会从 TaskQueue 中删除。 1015 | 1016 | ​ 1017 | 1018 | ``` 1019 | DelayedQueue 采用优先级队列 PriorityQueue延迟获取对象的阻塞队列。DelayQueue中的每个对象都必须实现Delayed 接口，并重写 compareTo 和 getDelay 方法。 1020 | ``` 1021 | 1022 | DelayQueue 提供了 put() 和 take() 的阻塞方法，可以向队列中添加对象和取出对象。对象被添加到 DelayQueue 后，会根据 compareTo() 方法进行优先级排序。getDelay() 方法用于计算消息延迟的剩余时间，只有 getDelay <=0 时，该对象才能从 DelayQueue 中取出。 1023 | 1024 | DelayQueue 在日常开发中最常用的场景就是实现重试机制。例如，接口调用失败或者请求超时后，可以将当前请求对象放入 DelayQueue，通过一个异步线程 take() 取出对象然后继续进行重试。如果还是请求失败，继续放回 DelayQueue。可以设置重试的最大次数以及采用指数退避算法设置对象的 deadline，如 2s、4s、8s、16s ……以此类推。DelayQueue的时间复杂度和Timer基本一致。 1025 | 1026 | ```java 1027 | 为了解决 Timer 的设计缺陷，JDK 提供了功能更加丰富的 ScheduledThreadPoolExecutor，多线程、相对时间、对异常 1028 | ``` 1029 | 1030 | ​ Timer 是单线程模式。如果某个 TimerTask 执行时间很久，会影响其他任务的调度。 1031 | 1032 | ​ Timer 的任务调度是基于系统绝对时间的，如果系统时间不正确，可能会出现问题。 1033 | 1034 | ​ TimerTask 如果执行出现异常，Timer 并不会捕获，会导致线程终止，其他任务永远不会执行。 1035 | 1036 | **时间轮原理分析** 1037 | 1038 | image-20210504175518335 1039 | 1040 | 根据任务的到期时间进行取余和取模，然后根据取余结果将任务分布到不同的 slot 中，每个slot中根据round值决定是否操作，每次轮询到指定slot时，总时遍历最少round的对象进行执行，这样新增、执行两个操作的时间复杂度都近似O(1)。如果冲突较大可以增加数组长度，或者采用多级时间轮的方式处理。 1041 | 1042 | ```java 1043 | public HashedWheelTimer( 1044 |         ThreadFactory threadFactory, //线程池，但是只创建了一个线程 1045 |         long tickDuration, //时针每次 tick 的时间，相当于时针间隔多久走到下一个 slot 1046 |         TimeUnit unit,  //表示 tickDuration 的时间单位，tickDuration * unit 1047 |         int ticksPerWheel,  //时间轮上一共有多少个 slot，默认 512 个。 1048 |         boolean leakDetection, 1049 |         long maxPendingTimeouts) {//最大允许等待任务数 1050 |     // 省略其他代码 1051 |     wheel = createWheel(ticksPerWheel); // 创建时间轮的环形数组结构 1052 |     mask = wheel.length - 1; // 用于快速取模的掩码 1053 |     long duration = unit.toNanos(tickDuration); // 转换成纳秒处理 1054 |     workerThread = threadFactory.newThread(worker); // 创建工作线程 1055 |     leak = leakDetection || !workerThread.isDaemon() ? leakDetector.track(this) : null; // 是否开启内存泄漏检测 1056 |     this.maxPendingTimeouts = maxPendingTimeouts; // 最大允许等待任务数，HashedWheelTimer 中任务超出该阈值时会抛出异常 1057 | } 1058 | ``` 1059 | 1060 | image-20210504175531294 1061 | 1062 | ​ **时间轮空推进问题** 1063 | 1064 | ​ Netty 中的时间轮是通过固定的时间间隔 tickDuration 进行推动的，如果长时间没有到期任务，那么会存在时间轮空推进的现象，从而造成一定的性能损耗。此外，如果任务的到期时间跨度很大，例如 A 任务 1s 后执行，B 任务 6 小时之后执行，也会造成空推进的问题。 1065 | 1066 | **Kafka解决方案** 1067 | 1068 | ​ **为了解决空推进的问题**，Kafka 借助 JDK 的 DelayQueue 来负责推进时间轮。DelayQueue 保存了时间轮中的每个 Bucket，并且根据 Bucket 的到期时间进行排序，最近的到期时间被放在 DelayQueue 的队头。Kafka 中会有一个线程来读取 DelayQueue 中的任务列表，**如果时间没有到，那么 DelayQueue 会一直处于阻塞状态**，从而解决空推进的问题。虽然DelayQueue 插入和删除的性能不是很好，但这其实就是一种权衡的策略，但是DelayQueue 只存放了 Bucket，Bucket 的数量并不多，相比空推进带来的影响是利大于弊的。 1069 | 1070 | ​ **为了解决任务时间跨度很大的问题**，Kafka 引入了层级时间轮，如下图所示。当任务的 deadline 超出当前所在层的时间轮表示范围时，就会尝试将任务添加到上一层时间轮中，跟钟表的时针、分针、秒针的转动规则是同一个道理。 1071 | 1072 | 1073 | 1074 | #### 3、MpscQueue 1075 | 1076 | 1077 | 1078 | 1079 | 1080 | #### 4、select、poll、epoll的区别 1081 | 1082 | **select** （windows）**poll **(linux)本质上和select没有区别，查询每个fd对应的设备状态，如果设备就绪则在设备等待队列中加入一项并继续遍历，如果遍历完所有fd后没有发现就绪设备，则挂起当前进程，直到设备就绪或者主动超时，被唤醒后它又要再次遍历fd。 1083 | 1084 | **epoll **支持水平触发和边缘触发，最大的特点在于边缘触发，它只告诉进程哪些fd刚刚变为就绪态，并且只会通知一次。还有一个特点是，epoll使用“事件”的就绪通知方式，通过epoll_ctl注册fd，一旦该fd就绪，内核就会采用类似callback的回调机制来激活该fd，epoll_wait便可以收到通知。 1085 | 1086 | 1087 | 1088 | **Epoll空轮询漏洞** 1089 | 1090 | 在 JDK 中， Epoll 的实现是存在漏洞的，即使 Selector 轮询的事件列表为空，NIO 线程一样可以被唤醒，导致 CPU 100% 占用。实际上 Netty 并没有从根源上解决该问题，而是巧妙地规避了这个问题。 1091 | 1092 | ```java 1093 | long time = System.nanoTime(); 1094 | if (/*事件轮询的持续时间大于等于 timeoutMillis*/) { 1095 | selectCnt = 1; 1096 | } else if (/*不正常的次数 selectCnt 达到阈值 512*/) { 1097 | //重建Select并且SelectionKey重新注册到新Selector上 1098 | selector = selectRebuildSelector(selectCnt); 1099 | } 1100 | ``` 1101 | 1102 | NioEventLoop 线程的可靠性至关重要，一旦 NioEventLoop 发生阻塞或者陷入空轮询，就会导致整个系统不可用。 1103 | 1104 | 1105 | 1106 | # 四、LEETCODE 1107 | 1108 | ### 【Python语法】 1109 | 1110 | ```python 1111 | reduce(function, iterable[, initializer]) 1112 | reduce(lambda x,y:x * y,ns) # 数组之乘积 (ns[0] * ns[1]) * ns[2] 1113 | reduce(lambda x,y:x + y,ns) # 数组之和 1114 | # 记忆化搜索 1115 | @functools.lru_cache(None) 1116 | res = helper(0,N,0) 1117 | helper.cache_clear() 1118 | tuple(ns) 可以hash做参数 1119 | # 大根堆 1120 | q = list(map(lambda x:-x,ns)) 1121 | heapq.heapify(q) 1122 | key = -heapq.heappop(q) 1123 | # 过滤函数 1124 | filter(function, iterable) 1125 | filter(lambda x: 2 < x < 10 and x % 2 == 0, range(18)) 1126 | filter(dfs, range(len(graph))) 1127 | # 除数 1128 | div, mod = divmod(sum(ns), 4) 1129 | random.randint(i,len(self.ns)-1) 1130 | #第一个降序，第二个升序 1131 | sorted(pss,key = lambda x:[x[0],-x[1]]) 1132 | 1133 | # 不可变str 常见函数 1134 | split(sep=None, maxsplit=-1) # 以sep来分割字符串 1135 | strip([chars]) # 去除首末两端的字符, 默认是 \r,\n," " 1136 | join(iterable) # 将iterable内的元素拼接成字符串,如','.join(['leet', 'code'])="leet,code" 1137 | replace(old, new[, count]) # 字符串替换, old to new 1138 | count(sub[, start[, end]]) # 统计子字符串sub的个数 1139 | startswith(prefix[, start[, end]]) # 以prefix开始的字符串 1140 | endswith(suffix[, start[, end]]) # 以suffix结束的字符串 1141 | cs in chrs: # chrs 中包含 cs 1142 | 1143 | # deque 常见函数 1144 | queue = deque([iterable[, maxlen]]) 1145 | queue.append(val) # 往右边添加一个元素 1146 | queue.appendleft(val) # 往左边添加一个元素 1147 | queue.clear() # 清空队列 1148 | queue.count(val) # 返回指定元素的出现次数 1149 | queue.insert(val[, start[, stop]]) # 在指定位置插入元素 1150 | queue.pop() # 获取最右边一个元素，并在队列中删除 1151 | queue.popleft() # 获取最左边一个元素，并在队列中删除 1152 | queue.reverse() # 队列反转 1153 | queue.remove(val) # 删除指定元素 1154 | queue.rotate(n=1) # 把右边元素放到左边 1155 | 1156 | # list 常见函数 1157 | lst.sort(*, key=None, reverse=False) 1158 | lst.append(val) # 也可以 lst = lst + [val] 1159 | lst.clear() # 清空列表 1160 | lst.count(val) # val个数 1161 | lst.pop(val=lst[-1]) # (默认)从末端移除一个值 1162 | lst.remove(val) # 移除 val 1163 | lst.reverse() # 反转 1164 | lst.insert(i, val) # 在 i 处插入 val 1165 | 1166 | # 字典dict 常见函数 1167 | d = defaultdict(lambda : value) # 取到不存在的值时不会报错，用{}时、需要设置get的default值 1168 | pop(key[, default]) # 通过键去删除键值对(若没有该键则返回default(没有设置default则报错)) 1169 | setdefault(key[, default]) # 设置默认值 1170 | update([other]) # 批量添加 1171 | get(key[, default]) # 通过键获取值(若没有该键可设置默认值, 预防报错) 1172 | clear() # 清空字典 1173 | keys() # 将字典的键组成新的可迭代对象 1174 | values() # 将字典中的值组成新的可迭代对象 1175 | items() # 将字典的键值对凑成一个个元组, 组成新的可迭代对象 1176 | dict1 = dict2 #两个字典完全相等，滑窗时可用 1177 | 1178 | # 集合set 常见函数 1179 | s = set(lambda : value) 1180 | add(elem) # 向集合中添加数据 1181 | update(*others) # 迭代着增加 1182 | clear() # 清空集合 1183 | discard(elem) # 删除集合中指定的值(不存在则不删除) 1184 | 1185 | # 堆heapq 常见函数 1186 | heap = [] # 建堆 1187 | heapq.heappush(heap,item) # 往堆中插入新值 1188 | heapq.heappop(heap) # 弹出最小的值 1189 | heap[0] # 查看堆中最小的值, 不弹出 1190 | heapq.heapify(x) # 以线性时间将一个列表转为堆 1191 | heapq.heappoppush(heap, item) # 弹出最小的值.并且将新的值插入其中. 1192 | heapq.merge(*iterables, key=None, reverse=False) # 将多个堆进行合并 1193 | heapq.nlargest(n, iterable, key=None) # 从堆中找出最大的 n 个数，key的作用和sorted( )方法里面的key类似, 用列表元素的某个属性和函数作为关键字 1194 | heapq.nsmallest(n, iterable, key=None) # 从堆中找出最小的 n 个数, 与 nlargest 相反 1195 | 1196 | 1197 | # 二分查找函数 1198 | bisect.bisect_left(ps, T, L=0, R=len(ns)) #二分左边界 1199 | bisect.bisect_right(ps, T, L=0, R=len(ns)) #二分右边界 1200 | bisect.insort_left(a, x, lo=0, hi=len(a)) # 二分插入到左侧 1201 | bisect.insort_right(a, x, lo=0, hi=len(a)) # 二分插入到右侧 1202 | 1203 | # bit操作 1204 | & 符号，x & y ，会将两个十进制数在二进制下进行与运算 1205 | | 符号，x | y ，会将两个十进制数在二进制下进行或运算 1206 | ^ 符号，x ^ y ，会将两个十进制数在二进制下进行异或运算 1207 | << 符号，x << y 左移操作，最右边用 0 填充 1208 | >> 符号，x >> y 右移操作，最左边用 0 填充 1209 | ~ 符号，~x ，按位取反操作，将 x 在二进制下的每一位取反 1210 | 1211 | # 整数集合set位运算 1212 | # 整数集合做标志时，可以做参数加速运算 1213 | vstd 访问 i ：vstd | (1 << i) 1214 | vstd 离开 i ：vstd & ~(1 << i) 1215 | vstd 不包含 i : not vstd & (1 << i) 1216 | 1217 | 并集 ：A | B 1218 | 交集 ：A & B 1219 | 全集 ：(1 << n) - 1 1220 | 补集 ：((1 << n) - 1) ^ A 1221 | 子集 ：(A & B) == B 1222 | 判断是否是 2 的幂 ：A & (A - 1) == 0 1223 | 最低位的 1 变为 0 ：n &= (n - 1) 1224 | while n: 1225 | n &= n - 1 1226 | ret += 1 1227 | 最低位的 1：A & (-A)，最低位的 1 一般记为 lowbit(A) 1228 | 1229 | # ^ ：匹配字符串开头 1230 | # [\+\-]：代表一个+字符或-字符 1231 | # ? ：前面一个字符可有可无 1232 | # \d ：一个数字 1233 | # + ：前面一个字符的一个或多个 1234 | # \D ：一个非数字字符 1235 | # * ：前面一个字符的0个或多个 1236 | matches = re.match('[ ]*([+-]?\d+)', s) 1237 | ``` 1238 | 1239 | 1240 | 1241 | ### 【背包模板】 1242 | 1243 | **「力扣」上的 0-1 背包问题：** 1244 | 1245 | - 组合问题模板 1246 | 1247 | ```python 1248 | #0-1背包，不可重复 1249 | for n in ns: 1250 | for i in range(T, n-1, -1): 1251 | dp[i] = max(dp[i], dp[i - n] + ws[i]) 1252 | #完全背包，可重复，无序，算重量 1253 | for n in ns: 1254 | for i in range(n, T+1): 1255 | dp[i] = max(dp[i], dp[i - n] + ws[i]) 1256 | #完全背包，可重复，有序，算次数 1257 | for i in range(1, T+1): 1258 | for n in ns: 1259 | dp[i] += dp[i-n] 1260 | ``` 1261 | 1262 | **✅377** 组合总和 Ⅳ 1263 | ✅**494** 目标和 1264 | ✅**518** 零钱兑换 II 1265 | 1266 | - True、False问题 1267 | 1268 | ```python 1269 | dp[i] |= dp[i-num] 1270 | ``` 1271 | 1272 | **✅139** 单词拆分 1273 | **✅416** 分割等和子集 1274 | 1275 | ```python 1276 | #特殊的可以使用bit数组 1277 | ``` 1278 | 1279 | - 最大最小问题： 1280 | 1281 | ```python 1282 | dp[i] = min(dp[i], dp[i-num]+1) 1283 | dp[i] = max(dp[i], dp[i-num]+1) 1284 | ``` 1285 | 1286 | ✅**474** 一和零 1287 | ✅**322** 零钱兑换 1288 | 1289 | 「力扣」第 **879** 题：盈利计划（困难）； 1290 | 「力扣」第 **1449** 题：数位成本和为目标值的最大数字（困难）。 1291 | 1292 | ### 【回溯模板】 1293 | 1294 | ```python 1295 | # 回溯算法，复杂度较高2^n或者N！，因为回溯算法就是暴力穷举，可用lru剪枝 1296 | @functools.lru_cache(None) 1297 | def backtrack(路径, 选择列表): 1298 | if 满足结束条件: 1299 | 结果.append(路径) 1300 | return 1301 | for 选择 in 选择列表: # 核心代码段 1302 | if vst[i]: # 辅助数组，减枝 1303 | continue 1304 | 做出选择 1305 | 递归执行backtrack 1306 | 撤销选择 1307 | ``` 1308 | 1309 | 「**剪枝**」第 **46** 题 全排列 第 **47** 题 全排列② 1310 | 1311 | ```python 1312 | # 剪枝 1313 | def backtrack(temp_list, length): 1314 | if length == n: 1315 | res.append(temp_list) 1316 | for i in range(n): 1317 | if not visited[i]: 1318 | visited[i] = 1 1319 | backtrack(temp_list + [nums[i]], length + 1) 1320 | visited[i] = 0 1321 | ``` 1322 | 1323 | 「**索引遍历**」第 **78** 题 子集 | 第 **47** 题 子集② | 第 **131** 题 分割字符串 1324 | 1325 | 第 **39 **题 组合 | 第 **40** 题 组合② | 第 **216** 题 组合③ 1326 | 1327 | ```python 1328 | # 索引遍历 1329 | def helper1(idx, n, temp_list): 1330 | if temp_list not in res: 1331 | res.append(temp_list) 1332 | for i in range(idx, n): 1333 | helper1(i + 1, n, temp_list + [nums[i]]) 1334 | ``` 1335 | 1336 | 「 **资源消耗**」第 **22** 题 夸号生成 1337 | 1338 | ```python 1339 | # 资源消耗 1340 | def backtrack(S, L, R): 1341 | if not L and not R: 1342 | ans.append(''.join(S)) 1343 | return 1344 | if L : backtrack(S + ['('], L-1, R) 1345 | if R > L : backtrack(S + [')'], L, R-1) 1346 | ``` 1347 | 1348 | 「**资源消耗**」第 **93** 题 复原IP 1349 | 1350 | ```python 1351 | 资源消耗 1352 | def backtrack(i, tmp, flag): 1353 | if i == n and flag == 0: 1354 | res.append(tmp[:-1]) 1355 | elif i bool: 1408 | if not p: 1409 | return not s 1410 | f = bool(s and p[0] in {s[0],'.'}) 1411 | if len(p) >= 2 and p[1] == "*": 1412 | return self.isMatch(s, p[2:]) or f and self.isMatch(s[1:], p) 1413 | else: 1414 | return f and self.isMatch(s[1:], p[1:]) 1415 | ``` 1416 | 1417 | ### 【并查集模板】 1418 | 1419 | ```python 1420 | #虚拟节点用以连接某一特征的全部节点，类似于链表的preHead 1421 | dummy 1422 | parent = {} 1423 | size = collections.defaultdict(lambda:1) 1424 | cnt = 0 1425 | def find(x): 1426 | parent.setdefault(x,x) 1427 | while x != parent[x]: 1428 | x = parent[x] 1429 | #路径压缩 parent[x] = parent[parent[x]]; 1430 | return x 1431 | def union(x,y): 1432 | nonlocal cnt 1433 | if connected(x,y): return 1434 | # 小的树挂到大的树上， 使树尽量平衡 1435 | xP = find(x) 1436 | yP = find(y) 1437 | if size[hP] < size[yP]: 1438 | parent[xP] = yP 1439 | else: 1440 | parent[yP] = xP 1441 | size[xP] += size[yP] 1442 | # 优化结束 1443 | parent[find(x)] = find(y) 1444 | # 不优化 1445 | cnt -= 1 1446 | return size[xP] 1447 | def connected(x, y): 1448 | return find(x) == find(y) 1449 | def add(self,x): 1450 | if x not in parent: 1451 | parent[x] = None 1452 | cnt += 1 1453 | # 检查是否有环 1454 | for a, b in edges: 1455 | if connected(a, b): 1456 | return True 1457 | union(a, b) 1458 | # 将每个集合组成以头为key的字典 1459 | res = collections.defaultdict(list) 1460 | for e in e2n: 1461 | res[uf.find(e)].append(e) 1462 | ``` 1463 | 1464 | ### 【拓扑排序模板】 1465 | 1466 | ```python 1467 | # 【拓扑排序模板】 1468 | ins = [0] * n 1469 | ous = collections.defaultdict(list) 1470 | for cur, pre in ps: 1471 | ins[cur] += 1 #入度 1472 | ous[pre].append(cur) #出度 1473 | res = list(filter(lambda x:ins[x]==0, range(n))) 1474 | q = collections.deque(res) 1475 | while q: 1476 | pre = q.popleft() 1477 | for cur in ous[pre]: #释放出度队列 1478 | ins[cur] -= 1 1479 | if not ins[cur]: 1480 | q.append(cur) #入度为0解锁 1481 | res.append(cur) 1482 | ``` 1483 | 1484 | ### **【单调栈模板】** 1485 | 1486 | ```python 1487 | # s中一般存索引 1488 | for i in range(len(ns): 1489 | while stack and ns[stack[-1]] <= ns[i]: # 单调递减栈 1490 | stack.pop() 1491 | # 业务逻辑 1492 | stack.append(i) 1493 | ``` 1494 | 1495 | 「**单调递增**」第 **84** 题 求最大矩形 1496 | 1497 | ```python 1498 | # 第 **84** 题 求最大矩形 1499 | for i in range(len(hs)): 1500 | while s and hs[i] < hs[s[-1]]: 1501 | base = s.pop() 1502 | if s: 1503 | H = hs[base] 1504 | W = i - s[-1] - 1 # 当前弹出的做高，当前与次小做宽 1505 | res = max(res, H * W) 1506 | s.append(i) 1507 | ``` 1508 | 1509 | 「**单调递增,考虑剩余**」第 **316** 题 去除重复字符 1510 | 1511 | ```python 1512 | # 第 **316** 题 去除重复字符 1513 | for i,c in enumerate(ss): 1514 | if c not in s: 1515 | while s and c < s[-1] and s[-1] in ss[i:]: 1516 | s.pop() 1517 | s.append(c) 1518 | ``` 1519 | 1520 | 「**单调递减**」第 **42** 题 接雨水 1521 | 1522 | ```python 1523 | # 第 **42** 题 接雨水 1524 | for i in range(len(hgt)): 1525 | while stack and hgt[i] > hgt[stack[-1]]: #递减栈 1526 | base = stack.pop() 1527 | if stack: 1528 | LH = hgt[stack[-1]] 1529 | W = i - stack[-1] - 1 1530 | H = min(LH,hgt[i]) - hgt[base] 1531 | res += W * H 1532 | stack.append(i) 1533 | ``` 1534 | 1535 | 「**单调递减**」第 **739** 题 每日温度 1536 | 1537 | ```python 1538 | # 第 **739** 题 每日温度 1539 | for i in range(len(T)-1,-1,-1): 1540 | while s and T[s[-1]] <= T[i] : #递减栈 1541 | s.pop() 1542 | res[i] = s[-1] - i if s else 0 1543 | s.append(i) 1544 | ``` 1545 | 1546 | ### 【二分模板】 1547 | 1548 | ```python 1549 | # 1355579 T=5 => 13(5)55579 返回2 1550 | # ps[i-1] < ps[i] <= ps[i+1] 1551 | bisect.bisect_left(ps, T, L=0, R=len(ns)) 1552 | # 1355579 T=5 => 13555(5)79 返回5 1553 | # ps[i-1] <= ps[i] < ps[i+1] 1554 | bisect.bisect_right(ps, T, L=0, R=len(ns)) 1555 | bisect.bisect(ps, T, L=0, R=len(ns)) 1556 | ``` 1557 | 1558 | 「**中位返回**」第 **33** 题 搜索旋转排序数组 | 第**374**题 猜数字大小 | 第**69**题 x平方根 1559 | 1560 | ```python 1561 | # 中位返回 1562 | while L <= R: 1563 | M = (L + R) // 2 1564 | if nums[M] == T: 1565 | return M 1566 | elif nums[M] < T: 1567 | L = M + 1 1568 | else: 1569 | R = M - 1 1570 | ``` 1571 | 1572 | 「**区域压缩**」第**278**题 第一个错误版本| 第**162**题 寻找峰值 | 第**153**题 寻找数组最小值 1573 | 1574 | ```python 1575 | # 区域压缩 1576 | while L < R: 1577 | M = (L + R) // 2 1578 | if need in s[L:M]: 1579 | R = M 1580 | else: 1581 | L = M + 1 1582 | ``` 1583 | 1584 | ### 【动态规划模板】 1585 | 1586 | #### 「**单串问题**」 1587 | 1588 | - 70 爬楼梯问题 1589 | - 801 使序列递增的最小交换次数 1590 | - 746 使用最小花费爬楼梯 1591 | - 300 最长上升子序列 1592 | 1593 | ```python 1594 | # 依赖前单个元素 1595 | dp[i] = dp[i-1] + ns[i] 1596 | # 依赖前部区域元素 1597 | for i in range(n) 1598 | for j in range(i) 1599 | dp[i] = min(dp[i], f(dp[j]) 1600 | ``` 1601 | 1602 | #### 「**单串加状态问题**」 1603 | 1604 | - 887 鸡蛋掉落 1605 | 1606 | ```python 1607 | # 鸡蛋掉落 1608 | while cur[K] < N: # 还剩 j 个蛋 测 ans 次 覆盖多少层 1609 | for j in range(1, K + 1): # 覆盖总层数 碎了 -1 次层数 + 1 + 没碎 -1 次层数 1610 | cur[j] = prev[j - 1] + 1 + prev[j] 1611 | ans += 1 1612 | prev = copy.deepcopy(cur) 1613 | ``` 1614 | 1615 | - 813 最大平均值分组 1616 | 1617 | ```python 1618 | # 813 最大平均值分组 1619 | for k in range(K-1): #循环k次 1620 | for i in range(N): #每次均依赖上次的结果 1621 | for j in range(i+1, N): 1622 | dp[i] = max(dp[i], avrg(i, j) + dp[j]) 1623 | ``` 1624 | 1625 | - 410 分割数组最大值 1626 | 1627 | ```python 1628 | # 410 分割数组最大值 1629 | for k in range(1,K): 1630 | for i in range(N): 1631 | for j in range(i): 1632 | # 0~i中分 k 段最大 即为 1633 | # 0~j中分k-1段最大 和 j到i的前缀和的最大 1634 | dp[i][k] = min(dp[i][k], max(dp[j][k-1], ps[i+1] - ps[j+1])) 1635 | ``` 1636 | 1637 | #### 「**经典双串LCS问题**」 1638 | 1639 | ```python 1640 | # 经典双串LCS问题 1641 | dp = [[0] * (M+1) for _ in range(N+1)] 1642 | for i in range(N): 1643 | for j in range(M): 1644 | if t1[i] == t2[j] : dp[i+1][j+1] = dp[i][j] + 1 1645 | else : dp[i+1][j+1] = max(dp[i][j+1],dp[i+1][j]) 1646 | ``` 1647 | 1648 | #### 「区间动态规划」 1649 | 1650 | - 5 最长回文子串 1651 | - 647 最多回文子串 1652 | - 516 最长回文子序列 1653 | - 1312 最长回文插入次数 1654 | 1655 | ```python 1656 | # dp[i][j] 代表从 i 到 j 的最长子串满足条件的数量 1657 | # i-- < j++ ==> i 在 0~j 范围内 -- 1658 | dp = [[0] * (N) for _ in range(N)] 1659 | for j in range(N): 1660 | dp[j][j] = 1 1661 | for i in range(j-1,-1,-1): 1662 | if ss[i] == ss[j]: 1663 | dp[i][j] = dp[i+1][j-1] +2 1664 | else : 1665 | dp[i][j] = max(dp[i+1][j],dp[i][j-1]) 1666 | ``` 1667 | 1668 | #### **「区间分治动态规划」** 1669 | 1670 | [486 预测赢家](https://leetcode-cn.com/problems/predict-the-winner/) 1671 | 1672 | [312 戳气球](***https://leetcode-cn.com/problems/burst-balloons/***) 1673 | 1674 | [664 奇怪的打印机](***https://leetcode-cn.com/problems/strange-printer/***) 1675 | 1676 | [546 移除盒子](***https://leetcode-cn.com/problems/remove-boxes/***) 1677 | 1678 | ```python 1679 | # 区间分治动态规划 1680 | def helper(self, ns: List[int]) : 1681 | N = len(ns) 1682 | dp = [[0] * N for _ in range(N+1)] 1683 | for l in range(N): # 长度从小到大 1684 | for i in range(N-l): # 以 i 为 开头 1685 | j = i + l # 以 j 为 终点 1686 | for k in range(i,j): # 以 k 为分割点，进行分治 1687 | // Todo 业务逻辑 1688 | ``` 1689 | 1690 | 「**卡特兰数**」 1691 | 1692 | ```python 1693 | # 卡特兰数 1694 | g(n) = g(0)*g(n-1) + g(1)*g(n-2) ...g(n-1)*g(0) 1695 | dp=[1] + [0] * n 1696 | for i in range(1,n+1): 1697 | for j in range(1,i+1): 1698 | dp[i] += dp[j-1] * dp[i-j] 1699 | ``` 1700 | 1701 | 1702 | 1703 | 1704 | 1705 | ### 【滑动窗口】 1706 | 1707 | ```PYTHON 1708 | """给定待查串s和目标串t""" 1709 | nd, wd = {}, {} 1710 | nd = collections.Counter(s1) 1711 | L, R = 0, 0 1712 | cnt = 0 # 满足条件个数 1713 | while R < len(s): # 窗口右边界不断扩大，本质是搜索问题的可能解 1714 | c = s[R] # 即将加入到窗口中的字符 1715 | R += 1 1716 | 更新窗口中的数据 1717 | while 满足窗口收缩条件： # 窗口的左边界收缩，本质是优化可行解 1718 | 记录或返回结果 1719 | d = s[L] # 即将从窗口中删除的字符 1720 | L += 1 1721 | 更新窗口中的数据 1722 | return 结果 1723 | 1724 | # 固定窗口 ,比滑动窗口更快一些 1725 | i = j = cnt = 0 1726 | for j in range(len(A)): 1727 | if A[j] == 0: 1728 | cnt += 1 1729 | if cnt > K: #不满足时 平移 1730 | if A[i] == 0: 1731 | cnt -= 1 1732 | i += 1 1733 | return j - i + 1 1734 | 1735 | for j in range(len(A)): 1736 | if A[j] == 0: 1737 | cnt += 1 1738 | while cnt > K: 1739 | if A[i] == 0: 1740 | cnt -= 1 1741 | i += 1 1742 | res = max(res, j - i + 1) 1743 | return res 1744 | 1745 | 1746 | 1747 | ``` 1748 | 1749 | ### 【前缀和】 1750 | 1751 | 「**累加和存位置**」 1752 | 1753 | 1371 最长偶数元音子数组 1754 | 1755 | 525 最长相等01子数组 1756 | 1757 | 325 最长和为k 子数组 1758 | 1759 | ```python 1760 | # 前缀和初始化 1761 | psd = {0: -1} 1762 | for i in range(len(s)): 1763 | t ^= cd.get(s[i], 0) # 业务逻辑 1764 | if t not in psd: 1765 | psd[t] = i # 第一次存入数组 1766 | else: 1767 | ans = max(ans, i - psd[t]) #已存入则开始计算 1768 | ``` 1769 | 1770 | 「**累加和存数量**」 1771 | 1772 | 560 和为K的子数组数量 1773 | 1774 | 统计优美子数组 1775 | 1776 | ```python 1777 | # 累加和存数量 1778 | psd = {0:1} 1779 | for i in range(len(ns)): 1780 | s += ns[i] 1781 | if s - T in psd: 1782 | ans += psd[s - T] # 存数量 1783 | psd[s] = psd.get(s,0) + 1 1784 | ``` 1785 | 1786 | 「**模K状态前缀和**」 1787 | 1788 | 523 连续和为 k 倍 的子数组（存索引） 1789 | 1790 | 974 和被k 整除 子数组数量（存数量） 1791 | 1792 | ```python 1793 | # 模K状态前缀和 1794 | psd = {0:-1} 1795 | ans = s = 0 1796 | for i in range(len(ns)): 1797 | s += ns[i] # 业务逻辑 1798 | if T != 0: s %= abs(T) # 模k状态做key，索引做值 1799 | if s not in psd: 1800 | psd[s] = i 1801 | elif i - psd[s] > 1: 1802 | return True 1803 | ``` 1804 | 1805 | **「矩阵前缀和」** 1806 | 1807 | - 363 不超过K的最大数值和 1808 | - 1074 和为目标值的子矩阵数量 1809 | 1810 | ```python 1811 | # 矩阵前缀和 1812 | for i in range(m): #固定左边界 1813 | ps = [0] * n 1814 | for j in range(i, m): #固定右边界 1815 | psS = 0 1816 | dct = {0:1} #初始只有一种可能 1817 | for k in range(n): # 以高做前缀和 1818 | ps[k] += mtx[j][k] # 每行前缀和 1819 | psS += ps[k] # n行前缀和 1820 | cnt += dct.get(psS - T, 0) # 满足条件cnt 1821 | dct[psS] = dct.get(psS,0) + 1 # 保存当前状态 1822 | return cnt 1823 | ``` 1824 | 1825 | 1826 | 1827 | 1828 | 1829 | 1830 | 1831 | ### 【双指针】 1832 | 1833 | ```python 1834 | # 双指针 1835 | def removeElement(self, ns: List[int], val: int) -> int: 1836 | slow = 0 1837 | n = len(ns) 1838 | for fast in range(n): 1839 | if ns[fast] != val: 1840 | ns[slow] = ns[fast] 1841 | slow += 1 1842 | return slow 1843 | ``` 1844 | 1845 | 1846 | 1847 | ### 【深度优先】 1848 | 1849 | 「**二叉树遍历模板**」 1850 | 1851 | ```python 1852 | # 递归 1853 | # 时间复杂度：O(n)，n为节点数，访问每个节点恰好一次。 1854 | # 空间复杂度：空间复杂度：O(h)，h为树的高度。最坏情况下需要空间O(n)，平均情况为O(logn) 1855 | 1856 | # 递归1：二叉树遍历最易理解和实现版本 1857 | class Solution: 1858 | def preOrd(self, root: TreeNode) -> List[int]: 1859 | if not root: 1860 | return [] 1861 | # 前序递归 1862 | return [root.val] + self.preOrd(root.left) + self.preOrd(root.right) 1863 | # # 中序递归 1864 | # return self.inOrd(root.left) + [root.val] + self.inOrd(root.right) 1865 | # # 后序递归 1866 | # return self.postOrd(root.left) + self.postOrd(root.right) + [root.val] 1867 | 1868 | # 递归2：通用模板，可以适应不同的题目，添加参数、增加返回条件、修改进入递归条件、自定义返回值 1869 | class Solution: 1870 | def preOrd(self, root: TreeNode) -> List[int]: 1871 | def dfs(cur): 1872 | if not cur: 1873 | return 1874 | # 前序递归 1875 | res.append(cur.val) 1876 | dfs(cur.left) 1877 | dfs(cur.right) 1878 | # # 中序递归 1879 | # dfs(cur.left) 1880 | # res.append(cur.val) 1881 | # dfs(cur.right) 1882 | # # 后序递归 1883 | # dfs(cur.left) 1884 | # dfs(cur.right) 1885 | # res.append(cur.val) 1886 | res = [] 1887 | dfs(root) 1888 | return res 1889 | 1890 | 1891 | # 迭代 1892 | # 时间复杂度：O(n)，n为节点数，访问每个节点恰好一次。 1893 | # 空间复杂度：O(h)，h为树的高度。取决于树的结构，最坏情况存储整棵树，即O(n) 1894 | # 迭代1：前序遍历最常用模板（后序同样可以用） 1895 | class Solution: 1896 | def preOrd(self, root: TreeNode) -> List[int]: 1897 | if not root: 1898 | return [] 1899 | res = [] 1900 | stack = [root] 1901 | # # 前序迭代模板：最常用的二叉树DFS迭代遍历模板 1902 | while stack: 1903 | cur = stack.pop() 1904 | res.append(cur.val) 1905 | if cur.right: 1906 | stack.append(cur.right) 1907 | if cur.left: 1908 | stack.append(cur.left) 1909 | return res 1910 | 1911 | # # 后序迭代，相同模板：将前序迭代进栈顺序稍作修改，最后得到的结果反转 1912 | # while stack: 1913 | # cur = stack.pop() 1914 | # if cur.left: 1915 | # stack.append(cur.left) 1916 | # if cur.right: 1917 | # stack.append(cur.right) 1918 | # res.append(cur.val) 1919 | # return res[::-1] 1920 | 1921 | # 迭代1：层序遍历最常用模板 1922 | class Solution: 1923 | def levelOrder(self, root: TreeNode) -> List[List[int]]: 1924 | if not root: 1925 | return [] 1926 | q = deque([root]) 1927 | res = [] 1928 | while q : 1929 | l = [] 1930 | for i in range(len(q)) : 1931 | t = q.popleft() 1932 | l.append(t.val) 1933 | if t.left : q.append(t.left) 1934 | if t.right : q.append(t.right) 1935 | res.append(l) 1936 | return res 1937 | 1938 | 1939 | # 迭代2：前、中、后序遍历通用模板（只需一个栈的空间） 1940 | class Solution: 1941 | def inOrd(self, root: TreeNode) -> List[int]: 1942 | res = [] 1943 | stack = [] 1944 | cur = root 1945 | # 中序，模板：先用指针找到每颗子树的最左下角，然后进行进出栈操作 1946 | while stack or cur: 1947 | while cur: 1948 | stack.append(cur) 1949 | cur = cur.left 1950 | cur = stack.pop() 1951 | res.append(cur.val) 1952 | cur = cur.right 1953 | return res 1954 | 1955 | # # 前序，相同模板 1956 | # while stack or cur: 1957 | # while cur: 1958 | # res.append(cur.val) 1959 | # stack.append(cur) 1960 | # cur = cur.left 1961 | # cur = stack.pop() 1962 | # cur = cur.right 1963 | # return res 1964 | 1965 | # # 后序，相同模板 1966 | # while stack or cur: 1967 | # while cur: 1968 | # res.append(cur.val) 1969 | # stack.append(cur) 1970 | # cur = cur.right 1971 | # cur = stack.pop() 1972 | # cur = cur.left 1973 | # return res[::-1] 1974 | 1975 | 1976 | # 迭代3：标记法迭代（需要双倍的空间来存储访问状态）： 1977 | # 前、中、后、层序通用模板，只需改变进栈顺序或即可实现前后中序遍历， 1978 | # 而层序遍历则使用队列先进先出。0表示当前未访问，1表示已访问。 1979 | class Solution: 1980 | def preOrd(self, root: TreeNode) -> List[int]: 1981 | res = [] 1982 | stack = [(0, root)] 1983 | while stack: 1984 | flag, cur = stack.pop() 1985 | if not cur: continue 1986 | if flag == 0: 1987 | # 前序，标记法 1988 | stack.append((0, cur.right)) 1989 | stack.append((0, cur.left)) 1990 | stack.append((1, cur)) 1991 | 1992 | # # 后序，标记法 1993 | # stack.append((1, cur)) 1994 | # stack.append((0, cur.right)) 1995 | # stack.append((0, cur.left)) 1996 | 1997 | # # 中序，标记法 1998 | # stack.append((0, cur.right)) 1999 | # stack.append((1, cur)) 2000 | # stack.append((0, cur.left)) 2001 | else: 2002 | res.append(cur.val) 2003 | return res 2004 | 2005 | # # 层序，标记法 2006 | # res = [] 2007 | # queue = [(0, root)] 2008 | # while queue: 2009 | # flag, cur = queue.pop(0) # 注意是队列，先进先出 2010 | # if not cur: continue 2011 | # if flag == 0: 2012 | # 层序遍历这三个的顺序无所谓，因为是队列，只弹出队首元素 2013 | # queue.append((1, cur)) 2014 | # queue.append((0, cur.left)) 2015 | # queue.append((0, cur.right)) 2016 | # else: 2017 | # res.append(cur.val) 2018 | # return res 2019 | 2020 | 2021 | 2022 | # 莫里斯遍历 2023 | # 时间复杂度：O(n)，n为节点数，看似超过O(n)，有的节点可能要访问两次，实际分析还是O(n) 2024 | # 空间复杂度：O(1)，如果在遍历过程中就输出节点值，则只需常数空间就能得到中序遍历结果，空间只需两个指针。 2025 | # 如果将结果储存最后输出，则空间复杂度还是O(n)。 2026 | 2027 | # PS：莫里斯遍历实际上是在原有二叉树的结构基础上，构造了线索二叉树， 2028 | # 线索二叉树定义为：原本为空的右子节点指向了中序遍历顺序之后的那个节点，把所有原本为空的左子节点都指向了中序遍历之前的那个节点 2029 | 2030 | # 此处只给出中序遍历，前序遍历只需修改输出顺序即可 2031 | # 而后序遍历，由于遍历是从根开始的，而线索二叉树是将为空的左右子节点连接到相应的顺序上，使其能够按照相应准则输出 2032 | # 但是后序遍历的根节点却已经没有额外的空间来标记自己下一个应该访问的节点， 2033 | # 所以这里需要建立一个临时节点dump，令其左孩子是root。并且还需要一个子过程，就是倒序输出某两个节点之间路径上的各个节点。 2034 | 2035 | # 莫里斯遍历，借助线索二叉树中序遍历（附前序遍历） 2036 | class Solution: 2037 | def inOrd(self, root: TreeNode) -> List[int]: 2038 | res = [] 2039 | # cur = pre = TreeNode(None) 2040 | cur = root 2041 | 2042 | while cur: 2043 | if not cur.left: 2044 | res.append(cur.val) 2045 | # print(cur.val) 2046 | cur = cur.right 2047 | else: 2048 | pre = cur.left 2049 | while pre.right and pre.right != cur: 2050 | pre = pre.right 2051 | if not pre.right: 2052 | # print(cur.val) 这里是前序遍历的代码，前序与中序的唯一差别 2053 | pre.right = cur 2054 | cur = cur.left 2055 | else: 2056 | pre.right = None 2057 | res.append(cur.val) 2058 | # print(cur.val) 2059 | cur = cur.right 2060 | return res 2061 | 2062 | 2063 | # N叉树遍历 2064 | # 时间复杂度：时间复杂度：O(M)，其中 M 是 N 叉树中的节点个数。每个节点只会入栈和出栈各一次。 2065 | # 空间复杂度：O(M)。在最坏的情况下，这棵 N 叉树只有 2 层，所有第 2 层的节点都是根节点的孩子。 2066 | # 将根节点推出栈后，需要将这些节点都放入栈，共有 M−1个节点，因此栈的大小为 O(M)。 2067 | 2068 | 2069 | # N叉树简洁递归 2070 | class Solution: 2071 | def preorder(self, root: 'Node') -> List[int]: 2072 | if not root: return [] 2073 | res = [root.val] 2074 | for node in root.children: 2075 | res.extend(self.preorder(node)) 2076 | return res 2077 | 2078 | # N叉树通用递归模板 2079 | class Solution: 2080 | def preorder(self, root: 'Node') -> List[int]: 2081 | res = [] 2082 | def helper(root): 2083 | if not root: 2084 | return 2085 | res.append(root.val) 2086 | for child in root.children: 2087 | helper(child) 2088 | helper(root) 2089 | return res 2090 | 2091 | # N叉树迭代方法 2092 | class Solution: 2093 | def preorder(self, root: 'Node') -> List[int]: 2094 | if not root: 2095 | return [] 2096 | s = [root] 2097 | # s.append(root) 2098 | res = [] 2099 | while s: 2100 | node = s.pop() 2101 | res.append(node.val) 2102 | # for child in node.children[::-1]: 2103 | # s.append(child) 2104 | s.extend(node.children[::-1]) 2105 | return res 2106 | ``` 2107 | 2108 | 2109 | 2110 | ### 【广度优先】 2111 | 2112 | ```python 2113 | # 「**无向图的遍历**」 2114 | q = collections.deque([i]) 2115 | while q: 2116 | cur = q.popleft() 2117 | for nxt in dt[cur]: 2118 | if not vst[nxt]: 2119 | vstd[nxt] = True 2120 | q.append(nxt) 2121 | ``` 2122 | 2123 | ```python 2124 | # 「**二叉树层序遍历**」 2125 | q = deque([root]) 2126 | res = [] 2127 | while q : 2128 | l = [] 2129 | for i in range(len(q)) : 2130 | t = q.popleft() 2131 | l.append(t.val) 2132 | if t.left : q.append(t.left) 2133 | if t.right : q.append(t.right) 2134 | res.append(l) 2135 | return res 2136 | ``` 2137 | 2138 | 2139 | 2140 | ### 【图论】 2141 | 2142 | **** 2143 | 2144 | ```python 2145 | #「Dijkstra最短路径」 2146 | dic = collections.defaultdict(list) 2147 | for u, v, w in edges: 2148 | dic[u].append([v, w]) 2149 | dic[v].append([u, w]) 2150 | q = [(0, n)] 2151 | dist = [-1] * (n + 1) 2152 | while q: 2153 | dis, cur = heapq.heappop(q) 2154 | if dist[cur] < 0: 2155 | dist[cur] = dis 2156 | for nxt, wi in dic[cur]: 2157 | heapq.heappush(q, [dis + wi, nxt]) 2158 | ``` 2159 | 2160 | **「Floyd 求图中路径」** 2161 | 2162 | ```python 2163 | # Floyd算法 求图中任意2点距离 2164 | ds = defaultdict(int) 2165 | st = set() 2166 | for i, (x, y) in enumerate(ess): 2167 | ds[(x, y)] = vs[i] 2168 | ds[(y, x)] = 1 / vs[i] 2169 | st.update({x,y}) 2170 | arr = list(st) 2171 | for k in arr: 2172 | for i in arr: 2173 | for j in arr: 2174 | if ds[(i, k)] and ds[(k, j)]: 2175 | ds[(i, j)] = ds[(i, k)] * ds[(k, j)] 2176 | ``` 2177 | 2178 | 2179 | 2180 | # 五、实战算法篇 2181 | 2182 | ### **1、**URL黑名单（布隆过滤器） 2183 | 2184 | **100亿黑名单URL，每个64B，问这个黑名单要怎么存？判断一个URL是否在黑名单中** 2185 | 2186 | ​ **散列表：** 2187 | 2188 | ​ 如果把黑名单看成一个集合，将其存在 hashmap 中，貌似太大了，需要 640G，明显不科学。 2189 | 2190 | ​ **布隆过滤器：** 2191 | 2192 | ​ 它实际上是一个很长的二进制矢量和一系列随机映射函数。 2193 | 2194 | ​ 它**可以用来判断一个元素是否在一个集合中**。它的优势是只需要占用很小的内存空间以及有着高效的查询效率。对于布隆过滤器而言，它的本质是一个**位数组**：位数组就是数组的每个元素都只占用 1 bit ，并且每个元素只能是 0 或者 1。 2195 | 2196 | ​ 在数组中的每一位都是二进制位。布隆过滤器除了一个位数组，还有 K 个哈希函数。当一个元素加入布隆过滤器中的时候，会进行如下操作： 2197 | 2198 | - 使用 K 个哈希函数对元素值进行 K 次计算，得到 K 个哈希值。 2199 | - 根据得到的哈希值，在位数组中把对应下标的值置为 1。 2200 | 2201 | 2202 | 2203 | ### 2、词频统计（分文件） 2204 | 2205 | **2GB内存在20亿整数中找到出现次数最多的数** 2206 | 2207 | ​ 通常做法是使用哈希表对出现的每一个数做词频统计，哈希表的key是某个整数，value记录整数出现的次数。本题的数据量是20亿，有可能一个数出现20亿次，则为了避免溢出，哈希表的key是32位（4B）,value也是 32位（4B），那么一条哈希表的记录就需要占用8B。 2208 | 2209 | ​ 当哈希表记录数为2亿个时，需要16亿个字节数（8\*2亿），需要至少1.6GB内存(16亿/2^30,1GB== 2 ^30个字节 == 10亿)。则20亿个记录，至少需要16GB的内存，不符合题目要求。 2210 | 2211 | ​ 解决办法是将20亿个数的大文件利用哈希函数分成16个小文件，根据哈希函数可以把20亿条数据均匀分布到16个文件上，同一种数不可能被哈希函数分到不同的小文件上，假设哈希函数够好。然后对每一个小文件用哈希函数来统计其中每种数出现的次数，这样我们就得到16个文件中出现次数最多的数，接着从16个数中选出次数最大的那个key即可。 2212 | 2213 | 2214 | 2215 | ### **3、未出现的数**（bit数组） 2216 | 2217 | **40亿个非负整数中找到没有出现的数** 2218 | 2219 | ​ 对于原问题，如果使用哈希表来保存出现过的数，那么最坏情况下是40亿个数都不相同，那么哈希表则需要保存40亿条数据，一个32位整数需要4B，那么40亿*4B = 160亿个字节，一般大概10亿个字节的数据需要1G的空间，那么大概需要16G的空间，这不符合要求。 2220 | 2221 | 　　我们换一种方式，申请一个bit数组，数组大小为4294967295，大概为40亿bit，40亿/8 = 5亿字节，那么需要0.5G空间， bit数组的每个位置有两种状态0和1，那么怎么使用这个bit数组呢？呵呵，数组的长度刚好满足我们整数的个数范围，那么数组的每个下标值对应4294967295中的一个数，逐个遍历40亿个无符号数，例如，遇到20，则bitArray[20] = 1；遇到666，则bitArray[666] = 1,遍历完所有的数，将数组相应位置变为1。 2222 | 2223 | 2224 | 2225 | **40亿个非负整数中找到一个没有出现的数，内存限制10MB** 2226 | 2227 | ​ 10亿个字节的数据大概需要1GB空间处理，那么10MB内存换算过来就是可以处理1千万字节的数据，也就是8千万bit，对于40亿非负整数如果申请bit数组的话，40亿bit / 0.8亿bit = 50，那么这样最少也得分50块来处理，下面就以64块来进行分析解答吧。 2228 | 2229 | **总结一下进阶的解法：** 2230 | 2231 | 1．根据10MB的内存限制，确定统计区间的大小，就是第二次遍历时的bitArr大小。 2232 | 2233 | 2．利用区间计数的方式，找到那个计数不足的区间，这个区间上肯定有没出现的数。 2234 | 2235 | 3．对这个区间上的数做bit map映射，再遍历bit map，找到一个没出现的数即可。 2236 | 2237 | **自己的想法** 2238 | 2239 | 如果只是找一个数，可以高位模运算，写到64个不同的文件，然后在最小的文件中通过bitArray一次处理掉。 2240 | 2241 | 2242 | 2243 | **40亿个无符号整数，1GB内存，找到所有出现两次的数** 2244 | 2245 | ​ 对于原问题，可以用bit map的方式来表示数出现的情况。具体地说，是申请一个长度为4294967295×2的bit类型的数组bitArr，用2个位置表示一个数出现的词频，1B占用8个bit，所以长度为4294967295×2的bit类型的数组占用1GB空间。怎么使用这个bitArr数组呢？遍历这40亿个无符号数，如果初次遇到num，就把bitArr[num*2 + 1]和bitArr[num*2]设置为01，如果第二次遇到num，就把bitArr[num*2+1]和bitArr[num*2]设置为10，如果第三次遇到num，就把bitArr[num*2+1]和bitArr[num*2]设置为11。以后再遇到num，发现此时bitArr[num*2+1]和bitArr[num*2]已经被设置为11，就不再做任何设置。遍历完成后，再依次遍历bitArr，如果发现bitArr[i*2+1]和bitArr[i*2]设置为10，那么i 就是出现了两次的数。 2246 | 2247 | 2248 | 2249 | ### **4、重复URL**（分机器） 2250 | 2251 | **找到100亿个URL中重复的URL** 2252 | 2253 | ​ 原问题的解法使用解决大数据问题的一种常规方法：把大文件通过哈希函数分配到机器，或者通过哈希函数把大文件拆成小文件。一直进行这种划分，直到划分的结果满足资源限制的要求。首先，你要向面试官询问在资源上的限制有哪些，包括内存、计算时间等要求。在明确了限制要求之后，可以将每条URL通过哈希函数分配到若干机器或者拆分成若干小文件，这里的“若干”由具体的资源限制来计算出精确的数量。 2254 | 2255 | ​ 例如，将100亿字节的大文件通过哈希函数分配到100台机器上，然后每一台机器分别统计分给自己的URL中是否有重复的URL，**同时哈希函数的性质决定了同一条URL不可能分给不同的机器；**或者在单机上将大文件通过哈希函数拆成1000个小文件，对每一个小文件再利用哈希表遍历，找出重复的URL；或者在分给机器或拆完文件之后，进行排序，排序过后再看是否有重复的URL出现。总之，牢记一点，很多大数据问题都离不开分流，要么是哈希函数把大文件的内容分配给不同的机器，要么是哈希函数把大文件拆成小文件，然后处理每一个小数量的集合。 2256 | 2257 | 2258 | 2259 | ### **5、TOPK搜索（小根堆）** 2260 | 2261 | **海量搜索词汇，找到最热TOP100词汇的方法** 2262 | 2263 | ​ 最开始还是用哈希分流的思路来处理，把包含百亿数据量的词汇文件分流到不同的机器上，具体多少台机器由面试官规定或者由更多的限制来决定。对每一台机器来说，如果分到的数据量依然很大，比如，内存不够或其他问题，可以再用哈希函数把每台机器的分流文件拆成更小的文件处理。 2264 | 2265 | ​ 处理每一个小文件的时候，哈希表统计每种词及其词频，哈希表记录建立完成后，再遍历哈希表，遍历哈希表的过程中使用大小为100的小根堆来选出每一个小文件的top 100（整体未排序的top 100）。每一个小文件都有自己词频的小根堆（整体未排序的top 100），将小根堆里的词按照词频排序，就得到了每个小文件的排序后top 100。然后把各个小文件排序后的top 100进行外排序或者继续利用小根堆，就可以选出每台机器上的top 100。不同机器之间的top100再进行外排序或者继续利用小根堆，最终求出整个百亿数据量中的top 100。对于top K 的问题，除哈希函数分流和用哈希表做词频统计之外，还经常用堆结构和外排序的手段进行处理。 2266 | 2267 | 2268 | 2269 | ### **6、中位数（单向二分查找）** 2270 | 2271 | **10MB内存，找到100亿整数的中位数** 2272 | 2273 | ①内存够：内存够还慌什么啊，直接把100亿个全部排序了，你用冒泡都可以...然后找到中间那个就可以了。但是你以为面试官会给你内存？？ 2274 | 2275 | ②内存不够：题目说是整数，我们认为是带符号的int,所以4字节，占32位。 2276 | 2277 | 假设100亿个数字保存在一个大文件中，依次读一部分文件到内存(不超过内存的限制)，将每个数字用二进制表示，比较二进制的最高位(第32位，符号位，0是正，1是负)，如果数字的最高位为0，则将这个数字写入 file_0文件中；如果最高位为 1，则将该数字写入file_1文件中。 2278 | 2279 | 从而将100亿个数字分成了两个文件，假设 file_0文件中有 60亿 个数字，file_1文件中有 40亿 个数字。那么中位数就在 file_0 文件中，并且是 file_0 文件中所有数字排序之后的第 10亿 个数字。（file_1中的数都是负数，file_0中的数都是正数，也即这里一共只有40亿个负数，那么排序之后的第50亿个数一定位于file_0中） 2280 | 2281 | 现在，我们只需要处理 file_0 文件了（不需要再考虑file_1文件）。对于 file_0 文件，同样采取上面的措施处理：将file_0文件依次读一部分到内存(不超内存限制)，将每个数字用二进制表示，比较二进制的 次高位（第31位），如果数字的次高位为0，写入file_0_0文件中；如果次高位为1，写入file_0_1文件 中。 2282 | 2283 | 现假设 file_0_0文件中有30亿个数字，file_0_1中也有30亿个数字，则中位数就是：file_0_0文件中的数字从小到大排序之后的第10亿个数字。 2284 | 2285 | 抛弃file_0_1文件，继续对 file_0_0文件 根据 次次高位(第30位) 划分，假设此次划分的两个文件为：file_0_0_0中有5亿个数字，file_0_0_1中有25亿个数字，那么中位数就是 file_0_0_1文件中的所有数字排序之后的 第 5亿 个数。 2286 | 2287 | 按照上述思路，直到划分的文件可直接加载进内存时，就可以直接对数字进行快速排序，找出中位数了。 2288 | 2289 | 2290 | 2291 | ### **7、短域名系统（缓存）** 2292 | 2293 | **设计短域名系统，将长URL转化成短的URL.** 2294 | 2295 | （1）利用放号器，初始值为0，对于每一个短链接生成请求，都递增放号器的值，再将此值转换为62进制（a-zA-Z0-9），比如第一次请求时放号器的值为0，对应62进制为a，第二次请求时放号器的值为1，对应62进制为b，第10001次请求时放号器的值为10000，对应62进制为sBc。 2296 | 2297 | （2）将短链接服务器域名与放号器的62进制值进行字符串连接，即为短链接的URL，比如：[t.cn/sBc。](http://t.cn/sBc。) 2298 | 2299 | （3）重定向过程：生成短链接之后，需要存储短链接到长链接的映射关系，即sBc -> URL，浏览器访问短链接服务器时，根据URL Path取到原始的链接，然后进行302重定向。映射关系可使用K-V存储，比如Redis或Memcache。 2300 | 2301 | 2302 | 2303 | ### **8、海量评论入库（消息队列）** 2304 | 2305 | **假设有这么一个场景，有一条新闻，新闻的评论量可能很大，如何设计评论的读和写** 2306 | 2307 | 前端页面直接给用户展示、通过消息队列异步方式入库 2308 | 2309 | 读可以进行读写分离、同时热点评论定时加载到缓存 2310 | 2311 | 2312 | 2313 | ### **9、在线/并发用户数（Redis）** 2314 | 2315 | ​ **显示网站的用户在线数的解决思路** 2316 | 2317 | ​ 维护在线用户表 2318 | 2319 | ​ 使用Redis统计 2320 | 2321 | **显示网站并发用户数** 2322 | 2323 | 1. 每当用户访问服务时，把该用户的 ID 写入ZSORT队列，权重为当前时间 2324 | 2. 根据权重(即时间)计算一分钟内该机构的用户数Zrange 2325 | 3. 删掉一分钟以上过期的用户Zrem 2326 | 2327 | 2328 | 2329 | ### 10、热门字符串（前缀树） 2330 | 2331 | 假设目前有 1000w 个记录（这些查询串的重复度比较高，虽然总数是 1000w，但如果除去重复后，则不超过 300w 个）。请统计最热门的 10 个查询串，要求使用的内存不能超过 1G。（一个查询串的重复度越高，说明查询它的用户越多，也就越热门。） 2332 | 2333 | **HashMap 法** 2334 | 2335 | 虽然字符串总数比较多，但去重后不超过 300w，因此，可以考虑把所有字符串及出现次数保存在一个 HashMap 中，所占用的空间为 300w*(255+4)≈777M（其中，4 表示整数占用的 4 个字节）。由此可见，1G 的内存空间完全够用。 2336 | 2337 | **思路如下**： 2338 | 2339 | 首先，遍历字符串，若不在 map 中，直接存入 map，value 记为 1；若在 map 中，则把对应的 value 加 1，这一步时间复杂度 `O(N)` 。 2340 | 2341 | 接着遍历 map，构建一个 10 个元素的小顶堆，若遍历到的字符串的出现次数大于堆顶字符串的出现次数，则进行替换，并将堆调整为小顶堆。 2342 | 2343 | 遍历结束后，堆中 10 个字符串就是出现次数最多的字符串。这一步时间复杂度 `O(Nlog10)` 。 2344 | 2345 | **前缀树法** 2346 | 2347 | 当这些字符串有大量相同前缀时，可以考虑使用前缀树来统计字符串出现的次数，树的结点保存字符串出现次数，0 表示没有出现。 2348 | 2349 | **思路如下**： 2350 | 2351 | 在遍历字符串时，在前缀树中查找，如果找到，则把结点中保存的字符串次数加 1，否则为这个字符串构建新结点，构建完成后把叶子结点中字符串的出现次数置为 1。 2352 | 2353 | 最后依然使用**小顶堆**来对字符串的出现次数进行排序。 2354 | 2355 | 2356 | 2357 | ### 11、红包算法 2358 | 2359 | 线性切割法，一个区间切N-1刀。越早越多 2360 | 2361 | 二倍均值法，【0 ~ 剩余金额 / 剩余人数 * 2】中随机，相对均匀 2362 | 2363 | 2364 | 2365 | 2366 | 2367 | 2368 | 2369 | 2370 | 2371 | ![img](https://tva1.sinaimg.cn/large/008eGmZEly1goqpbvl5pvj30qu0gcgm0.jpg) 2372 | 2373 | ![img](https://tva1.sinaimg.cn/large/008eGmZEly1goqpc3hz9dj31450ggq8k.jpg) 2374 | 2375 | ### 11、手写快排 2376 | 2377 | ```java 2378 | public class QuickSort { 2379 | public static void swap(int[] arr, int i, int j) { 2380 | int tmp = arr[i]; 2381 | arr[i] = arr[j]; 2382 | arr[j] = tmp; 2383 | } 2384 | /* 常规快排 */ 2385 | public static void quickSort1(int[] arr, int L , int R) { 2386 | if (L > R) return; 2387 | int M = partition(arr, L, R); 2388 | quickSort1(arr, L, M - 1); 2389 | quickSort1(arr, M + 1, R); 2390 | } 2391 | public static int partition(int[] arr, int L, int R) { 2392 | if (L > R) return -1; 2393 | if (L == R) return L; 2394 | int lessEqual = L - 1; 2395 | int index = L; 2396 | while (index < R) { 2397 | if (arr[index] <= arr[R]) 2398 | swap(arr, index, ++lessEqual); 2399 | index++; 2400 | } 2401 | swap(arr, ++lessEqual, R); 2402 | return lessEqual; 2403 | } 2404 | /* 荷兰国旗 */ 2405 | public static void quickSort2(int[] arr, int L, int R) { 2406 | if (L > R) return; 2407 | int[] equalArea = netherlandsFlag(arr, L, R); 2408 | quickSort2(arr, L, equalArea[0] - 1); 2409 | quickSort2(arr, equalArea[1] + 1, R); 2410 | } 2411 | public static int[] netherlandsFlag(int[] arr, int L, int R) { 2412 | if (L > R) return new int[] { -1, -1 }; 2413 | if (L == R) return new int[] { L, R }; 2414 | int less = L - 1; 2415 | int more = R; 2416 | int index = L; 2417 | while (index < more) { 2418 | if (arr[index] == arr[R]) { 2419 | index++; 2420 | } else if (arr[index] < arr[R]) { 2421 | swap(arr, index++, ++less); 2422 | } else { 2423 | swap(arr, index, --more); 2424 | } 2425 | } 2426 | swap(arr, more, R); 2427 | return new int[] { less + 1, more }; 2428 | } 2429 | 2430 | // for test 2431 | public static void main(String[] args) { 2432 | int testTime = 1; 2433 | int maxSize = 10000000; 2434 | int maxValue = 100000; 2435 | boolean succeed = true; 2436 | long T1=0,T2=0; 2437 | for (int i = 0; i < testTime; i++) { 2438 | int[] arr1 = generateRandomArray(maxSize, maxValue); 2439 | int[] arr2 = copyArray(arr1); 2440 | int[] arr3 = copyArray(arr1); 2441 | // int[] arr1 = {9,8,7,6,5,4,3,2,1}; 2442 | long t1 = System.currentTimeMillis(); 2443 | quickSort1(arr1,0,arr1.length-1); 2444 | long t2 = System.currentTimeMillis(); 2445 | quickSort2(arr2,0,arr2.length-1); 2446 | long t3 = System.currentTimeMillis(); 2447 | T1 += (t2-t1); 2448 | T2 += (t3-t2); 2449 | if (!isEqual(arr1, arr2) || !isEqual(arr2, arr3)) { 2450 | succeed = false; 2451 | break; 2452 | } 2453 | } 2454 | System.out.println(T1+" "+T2); 2455 | // System.out.println(succeed ? "Nice!" : "Oops!"); 2456 | } 2457 | 2458 | private static int[] generateRandomArray(int maxSize, int maxValue) { 2459 | int[] arr = new int[(int) ((maxSize + 1) * Math.random())]; 2460 | for (int i = 0; i < arr.length; i++) { 2461 | arr[i] = (int) ((maxValue + 1) * Math.random()) 2462 | - (int) (maxValue * Math.random()); 2463 | } 2464 | return arr; 2465 | } 2466 | private static int[] copyArray(int[] arr) { 2467 | if (arr == null) return null; 2468 | int[] res = new int[arr.length]; 2469 | for (int i = 0; i < arr.length; i++) { 2470 | res[i] = arr[i]; 2471 | } 2472 | return res; 2473 | } 2474 | private static boolean isEqual(int[] arr1, int[] arr2) { 2475 | if ((arr1 == null && arr2 != null) || (arr1 != null && arr2 == null)) 2476 | return false; 2477 | if (arr1 == null && arr2 == null) 2478 | return true; 2479 | if (arr1.length != arr2.length) 2480 | return false; 2481 | for (int i = 0; i < arr1.length; i++) 2482 | if (arr1[i] != arr2[i]) 2483 | return false; 2484 | return true; 2485 | } 2486 | private static void printArray(int[] arr) { 2487 | if (arr == null) 2488 | return; 2489 | for (int i = 0; i < arr.length; i++) 2490 | System.out.print(arr[i] + " "); 2491 | System.out.println(); 2492 | } 2493 | } 2494 | ``` 2495 | 2496 | ### 12、手写归并 2497 | 2498 | ```java 2499 | public static void merge(int[] arr, int L, int M, int R) { 2500 | int[] help = new int[R - L + 1]; 2501 | int i = 0; 2502 | int p1 = L; 2503 | int p2 = M + 1; 2504 | while (p1 <= M && p2 <= R) 2505 | help[i++] = arr[p1] <= arr[p2] ? arr[p1++] : arr[p2++]; 2506 | while (p1 <= M) 2507 | help[i++] = arr[p1++]; 2508 | while (p2 <= R) 2509 | help[i++] = arr[p2++]; 2510 | for (i = 0; i < help.length; i++) 2511 | arr[L + i] = help[i]; 2512 | } 2513 | public static void mergeSort(int[] arr, int L, int R) { 2514 | if (L == R) 2515 | return; 2516 | int mid = L + ((R - L) >> 1); 2517 | process(arr, L, mid); 2518 | process(arr, mid + 1, R); 2519 | merge(arr, L, mid, R); 2520 | } 2521 | public static void main(String[] args) { 2522 | int[] arr1 = {9,8,7,6,5,4,3,2,1}; 2523 | mergeSort(arr, 0, arr.length - 1); 2524 | printArray(arr); 2525 | } 2526 | ``` 2527 | 2528 | ### 13、手写堆排 2529 | 2530 | ```java 2531 | // 堆排序额外空间复杂度O(1) 2532 | public static void heapSort(int[] arr) { 2533 | if (arr == null || arr.length < 2) 2534 | return; 2535 | for (int i = arr.length - 1; i >= 0; i--) 2536 | heapify(arr, i, arr.length); 2537 | int heapSize = arr.length; 2538 | swap(arr, 0, --heapSize); 2539 | // O(N*logN) 2540 | while (heapSize > 0) { // O(N) 2541 | heapify(arr, 0, heapSize); // O(logN) 2542 | swap(arr, 0, --heapSize); // O(1) 2543 | } 2544 | } 2545 | // arr[index]刚来的数，往上 2546 | public static void heapInsert(int[] arr, int index) { 2547 | while (arr[index] > arr[(index - 1) / 2]) { 2548 | swap(arr, index, (index - 1) / 2); 2549 | index = (index - 1) / 2; 2550 | } 2551 | } 2552 | // arr[index]位置的数，能否往下移动 2553 | public static void heapify(int[] arr, int index, int heapSize) { 2554 | int left = index * 2 + 1; // 左孩子的下标 2555 | while (left < heapSize) { // 下方还有孩子的时候 2556 | // 两个孩子中，谁的值大，把下标给largest 2557 | // 1）只有左孩子，left -> largest 2558 | // 2) 同时有左孩子和右孩子，右孩子的值<= 左孩子的值，left -> largest 2559 | // 3) 同时有左孩子和右孩子并且右孩子的值> 左孩子的值， right -> largest 2560 | int largest = left+1 < heapSize && arr[left+1]> arr[left] ? left+1 : left; 2561 | // 父和较大的孩子之间，谁的值大，把下标给largest 2562 | largest = arr[largest] > arr[index] ? largest : index; 2563 | if (largest == index) 2564 | break; 2565 | swap(arr, largest, index); 2566 | index = largest; 2567 | left = index * 2 + 1; 2568 | } 2569 | } 2570 | public static void swap(int[] arr, int i, int j) { 2571 | int tmp = arr[i]; 2572 | arr[i] = arr[j]; 2573 | arr[j] = tmp; 2574 | } 2575 | public static void main(String[] args) { 2576 | int[] arr1 = {9,8,7,6,5,4,3,2,1}; 2577 | heapSort(arr1); 2578 | printArray(arr1); 2579 | } 2580 | ``` 2581 | 2582 | 2583 | 2584 | ### 14、手写单例 2585 | 2586 | ```java 2587 | public class Singleton { 2588 | private volatile static Singleton singleton; 2589 | private Singleton() {} 2590 | public static Singleton getSingleton() { 2591 | if (singleton == null) { 2592 | synchronized (Singleton.class) { 2593 | if (singleton == null) { 2594 | singleton = new Singleton(); 2595 | } 2596 | } 2597 | } 2598 | return singleton; 2599 | } 2600 | } 2601 | ``` 2602 | 2603 | 2604 | 2605 | ### 15、手写LRUcache 2606 | 2607 | ```java 2608 | // 基于linkedHashMap 2609 | public class LRUCache { 2610 | private LinkedHashMap cache; 2611 | private int capacity; //容量大小 2612 | public LRUCache(int capacity) { 2613 | cache = new LinkedHashMap<>(capacity); 2614 | this.capacity = capacity; 2615 | } 2616 | public int get(int key) { 2617 | //缓存中不存在此key，直接返回 2618 | if(!cache.containsKey(key)) { 2619 | return -1; 2620 | } 2621 | int res = cache.get(key); 2622 | cache.remove(key); //先从链表中删除 2623 | cache.put(key,res); //再把该节点放到链表末尾处 2624 | return res; 2625 | } 2626 | public void put(int key,int value) { 2627 | if(cache.containsKey(key)) { 2628 | cache.remove(key); //已经存在，在当前链表移除 2629 | } 2630 | if(capacity == cache.size()) { 2631 | //cache已满，删除链表头位置 2632 | Set keySet = cache.keySet(); 2633 | Iterator iterator = keySet.iterator(); 2634 | cache.remove(iterator.next()); 2635 | } 2636 | cache.put(key,value); //插入到链表末尾 2637 | } 2638 | } 2639 | ``` 2640 | 2641 | 2642 | 2643 | ```java 2644 | //手写双向链表 2645 | class LRUCache { 2646 | class DNode { 2647 | DNode prev; 2648 | DNode next; 2649 | int val; 2650 | int key; 2651 | } 2652 | Map map = new HashMap<>(); 2653 | DNode head, tail; 2654 | int cap; 2655 | public LRUCache(int capacity) { 2656 | head = new DNode(); 2657 | tail = new DNode(); 2658 | head.next = tail; 2659 | tail.prev = head; 2660 | cap = capacity; 2661 | } 2662 | public int get(int key) { 2663 | if (map.containsKey(key)) { 2664 | DNode node = map.get(key); 2665 | removeNode(node); 2666 | addToHead(node); 2667 | return node.val; 2668 | } else { 2669 | return -1; 2670 | } 2671 | } 2672 | public void put(int key, int value) { 2673 | if (map.containsKey(key)) { 2674 | DNode node = map.get(key); 2675 | node.val = value; 2676 | removeNode(node); 2677 | addToHead(node); 2678 | } else { 2679 | DNode newNode = new DNode(); 2680 | newNode.val = value; 2681 | newNode.key = key; 2682 | addToHead(newNode); 2683 | map.put(key, newNode); 2684 | if (map.size() > cap) { 2685 | map.remove(tail.prev.key); 2686 | removeNode(tail.prev); 2687 | } 2688 | } 2689 | } 2690 | public void removeNode(DNode node) { 2691 | DNode prevNode = node.prev; 2692 | DNode nextNode = node.next; 2693 | prevNode.next = nextNode; 2694 | nextNode.prev = prevNode; 2695 | } 2696 | public void addToHead(DNode node) { 2697 | DNode firstNode = head.next; 2698 | head.next = node; 2699 | node.prev = head; 2700 | node.next = firstNode; 2701 | firstNode.prev = node; 2702 | } 2703 | } 2704 | 2705 | ``` 2706 | 2707 | 2708 | 2709 | ### **16、手写线程池** 2710 | 2711 | ```java 2712 | package com.concurrent.pool; 2713 | import java.util.HashSet; 2714 | import java.util.Set; 2715 | import java.util.concurrent.ArrayBlockingQueue; 2716 | import java.util.concurrent.BlockingQueue; 2717 | public class MySelfThreadPool { 2718 | //默认线程池中的线程的数量 2719 | private static final int WORK_NUM = 5; 2720 | //默认处理任务的数量 2721 | private static final int TASK_NUM = 100; 2722 | private int workNum;//线程数量 2723 | private int taskNum;//任务数量 2724 | private final Set workThreads;//保存线程的集合 2725 | private final BlockingQueue taskQueue;//阻塞有序队列存放任务 2726 | public MySelfThreadPool() { 2727 | this(WORK_NUM, TASK_NUM); 2728 | } 2729 | public MySelfThreadPool(int workNum, int taskNum) { 2730 | if (workNum <= 0) workNum = WORK_NUM; 2731 | if (taskNum <= 0) taskNum = TASK_NUM; 2732 | taskQueue = new ArrayBlockingQueue<>(taskNum); 2733 | this.workNum = workNum; 2734 | this.taskNum = taskNum; 2735 | workThreads = new HashSet<>(); 2736 | //启动一定数量的线程数，从队列中获取任务处理 2737 | for (int i=0;i container = new ArrayList<>(); 2937 | private volatile int size; 2938 | private volatile int capacity; 2939 | private Lock lock = new ReentrantLock(); 2940 | private final Condition isNull = lock.newCondition(); 2941 | private final Condition isFull = lock.newCondition(); 2942 | blockQueue(int capacity) { 2943 | this.capacity = capacity; 2944 | } 2945 | public void add(int data) { 2946 | try { 2947 | lock.lock(); 2948 | try { 2949 | while (size >= capacity) { 2950 | System.out.println("阻塞队列满了"); 2951 | isFull.await(); 2952 | } 2953 | } catch (Exception e) { 2954 | isFull.signal(); 2955 | e.printStackTrace(); 2956 | } 2957 | ++size; 2958 | container.add(data); 2959 | isNull.signal(); 2960 | } finally { 2961 | lock.unlock(); 2962 | } 2963 | } 2964 | public int take() { 2965 | try { 2966 | lock.lock(); 2967 | try { 2968 | while (size == 0) { 2969 | System.out.println("阻塞队列空了"); 2970 | isNull.await(); 2971 | } 2972 | } catch (Exception e) { 2973 | isNull.signal(); 2974 | e.printStackTrace(); 2975 | } 2976 | --size; 2977 | int res = container.get(0); 2978 | container.remove(0); 2979 | isFull.signal(); 2980 | return res; 2981 | } finally { 2982 | lock.unlock(); 2983 | } 2984 | } 2985 | } 2986 | 2987 | public static void main(String[] args) { 2988 | AxinBlockQueue queue = new AxinBlockQueue(5); 2989 | Thread t1 = new Thread(() -> { 2990 | for (int i = 0; i < 100; i++) { 2991 | queue.add(i); 2992 | System.out.println("塞入" + i); 2993 | try { 2994 | Thread.sleep(500); 2995 | } catch (InterruptedException e) { 2996 | e.printStackTrace(); 2997 | } 2998 | } 2999 | }); 3000 | Thread t2 = new Thread(() -> { 3001 | for (; ; ) { 3002 | System.out.println("消费"+queue.take()); 3003 | try { 3004 | Thread.sleep(800); 3005 | } catch (InterruptedException e) { 3006 | e.printStackTrace(); 3007 | } 3008 | } 3009 | 3010 | }); 3011 | t1.start(); 3012 | t2.start(); 3013 | } 3014 | ``` 3015 | 3016 | 3017 | 3018 | 3019 | 3020 | ### **19、手写多线程交替打印ABC** 3021 | 3022 | ```java 3023 | package com.demo.test; 3024 | import java.util.concurrent.locks.Condition; 3025 | import java.util.concurrent.locks.ReentrantLock; 3026 | public class syncPrinter implements Runnable{ 3027 | // 打印次数 3028 | private static final int PRINT_COUNT = 10; 3029 | private final ReentrantLock reentrantLock; 3030 | private final Condition thisCondtion; 3031 | private final Condition nextCondtion; 3032 | private final char printChar; 3033 | public syncPrinter(ReentrantLock reentrantLock, Condition thisCondtion, Condition nextCondition, char printChar) { 3034 | this.reentrantLock = reentrantLock; 3035 | this.nextCondtion = nextCondition; 3036 | this.thisCondtion = thisCondtion; 3037 | this.printChar = printChar; 3038 | } 3039 | @Override 3040 | public void run() { 3041 | // 获取打印锁 进入临界区 3042 | reentrantLock.lock(); 3043 | try { 3044 | // 连续打印PRINT_COUNT次 3045 | for (int i = 0; i < PRINT_COUNT; i++) { 3046 | //打印字符 3047 | System.out.print(printChar); 3048 | // 使用nextCondition唤醒下一个线程 3049 | // 因为只有一个线程在等待，所以signal或者signalAll都可以 3050 | nextCondtion.signal(); 3051 | // 不是最后一次则通过thisCondtion等待被唤醒 3052 | // 必须要加判断，不然虽然能够打印10次，但10次后就会直接死锁 3053 | if (i < PRINT_COUNT - 1) { 3054 | try { 3055 | // 本线程让出锁并等待唤醒 3056 | thisCondtion.await(); 3057 | } catch (InterruptedException e) { 3058 | e.printStackTrace(); 3059 | } 3060 | } 3061 | } 3062 | } finally { 3063 | reentrantLock.unlock(); 3064 | } 3065 | } 3066 | 3067 | public static void main(String[] args) throws InterruptedException { 3068 | ReentrantLock lock = new ReentrantLock(); 3069 | Condition conditionA = lock.newCondition(); 3070 | Condition conditionB = lock.newCondition(); 3071 | Condition conditionC = lock.newCondition(); 3072 | Thread printA = new Thread(new syncPrinter(lock, conditionA, conditionB,'A')); 3073 | Thread printB = new Thread(new syncPrinter(lock, conditionB, conditionC,'B')); 3074 | Thread printC = new Thread(new syncPrinter(lock, conditionC, conditionA,'C')); 3075 | printA.start(); 3076 | Thread.sleep(100); 3077 | printB.start(); 3078 | Thread.sleep(100); 3079 | printC.start(); 3080 | } 3081 | } 3082 | ``` 3083 | 3084 | 3085 | 3086 | ### 20、交替打印FooBar 3087 | 3088 | ```java 3089 | //手太阴肺经 BLOCKING Queue 3090 | public class FooBar { 3091 | private int n; 3092 | private BlockingQueue bar = new LinkedBlockingQueue<>(1); 3093 | private BlockingQueue foo = new LinkedBlockingQueue<>(1); 3094 | public FooBar(int n) { 3095 | this.n = n; 3096 | } 3097 | public void foo(Runnable printFoo) throws InterruptedException { 3098 | for (int i = 0; i < n; i++) { 3099 | foo.put(i); 3100 | printFoo.run(); 3101 | bar.put(i); 3102 | } 3103 | } 3104 | public void bar(Runnable printBar) throws InterruptedException { 3105 | for (int i = 0; i < n; i++) { 3106 | bar.take(); 3107 | printBar.run(); 3108 | foo.take(); 3109 | } 3110 | } 3111 | } 3112 | 3113 | //手阳明大肠经CyclicBarrier 控制先后 3114 | class FooBar6 { 3115 | private int n; 3116 | public FooBar6(int n) { 3117 | this.n = n; 3118 | } 3119 | CyclicBarrier cb = new CyclicBarrier(2); 3120 | volatile boolean fin = true; 3121 | public void foo(Runnable printFoo) throws InterruptedException { 3122 | for (int i = 0; i < n; i++) { 3123 | while(!fin); 3124 | printFoo.run(); 3125 | fin = false; 3126 | try { 3127 | cb.await(); 3128 | } catch (BrokenBarrierException e) {} 3129 | } 3130 | } 3131 | public void bar(Runnable printBar) throws InterruptedException { 3132 | for (int i = 0; i < n; i++) { 3133 | try { 3134 | cb.await(); 3135 | } catch (BrokenBarrierException e) {} 3136 | printBar.run(); 3137 | fin = true; 3138 | } 3139 | } 3140 | } 3141 | 3142 | //手少阴心经 自旋 + 让出CPU 3143 | class FooBar5 { 3144 | private int n; 3145 | 3146 | public FooBar5(int n) { 3147 | this.n = n; 3148 | } 3149 | volatile boolean permitFoo = true; 3150 | public void foo(Runnable printFoo) throws InterruptedException { 3151 | for (int i = 0; i < n; ) { 3152 | if(permitFoo) { 3153 | printFoo.run(); 3154 | i++; 3155 | permitFoo = false; 3156 | }else{ 3157 | Thread.yield(); 3158 | } 3159 | } 3160 | } 3161 | public void bar(Runnable printBar) throws InterruptedException { 3162 | for (int i = 0; i < n; ) { 3163 | if(!permitFoo) { 3164 | printBar.run(); 3165 | i++; 3166 | permitFoo = true; 3167 | }else{ 3168 | Thread.yield(); 3169 | } 3170 | } 3171 | } 3172 | } 3173 | 3174 | 3175 | 3176 | //手少阳三焦经 可重入锁 + Condition 3177 | class FooBar4 { 3178 | private int n; 3179 | 3180 | public FooBar4(int n) { 3181 | this.n = n; 3182 | } 3183 | Lock lock = new ReentrantLock(true); 3184 | private final Condition foo = lock.newCondition(); 3185 | volatile boolean flag = true; 3186 | public void foo(Runnable printFoo) throws InterruptedException { 3187 | for (int i = 0; i < n; i++) { 3188 | lock.lock(); 3189 | try { 3190 | while(!flag) { 3191 | foo.await(); 3192 | } 3193 | printFoo.run(); 3194 | flag = false; 3195 | foo.signal(); 3196 | }finally { 3197 | lock.unlock(); 3198 | } 3199 | } 3200 | } 3201 | 3202 | public void bar(Runnable printBar) throws InterruptedException { 3203 | for (int i = 0; i < n;i++) { 3204 | lock.lock(); 3205 | try { 3206 | while(flag) { 3207 | foo.await(); 3208 | } 3209 | printBar.run(); 3210 | flag = true; 3211 | foo.signal(); 3212 | }finally { 3213 | lock.unlock(); 3214 | } 3215 | } 3216 | } 3217 | } 3218 | 3219 | //手厥阴心包经 synchronized + 标志位 + 唤醒 3220 | class FooBar3 { 3221 | private int n; 3222 | // 标志位，控制执行顺序，true执行printFoo，false执行printBar 3223 | private volatile boolean type = true; 3224 | private final Object foo= new Object(); // 锁标志 3225 | 3226 | public FooBar3(int n) { 3227 | this.n = n; 3228 | } 3229 | public void foo(Runnable printFoo) throws InterruptedException { 3230 | for (int i = 0; i < n; i++) { 3231 | synchronized (foo) { 3232 | while(!type){ 3233 | foo.wait(); 3234 | } 3235 | printFoo.run(); 3236 | type = false; 3237 | foo.notifyAll(); 3238 | } 3239 | } 3240 | } 3241 | 3242 | public void bar(Runnable printBar) throws InterruptedException { 3243 | for (int i = 0; i < n; i++) { 3244 | synchronized (foo) { 3245 | while(type){ 3246 | foo.wait(); 3247 | } 3248 | printBar.run(); 3249 | type = true; 3250 | foo.notifyAll(); 3251 | } 3252 | } 3253 | } 3254 | } 3255 | 3256 | 3257 | //手太阳小肠经 信号量 适合控制顺序 3258 | class FooBar2 { 3259 | private int n; 3260 | private Semaphore foo = new Semaphore(1); 3261 | private Semaphore bar = new Semaphore(0); 3262 | public FooBar2(int n) { 3263 | this.n = n; 3264 | } 3265 | 3266 | public void foo(Runnable printFoo) throws InterruptedException { 3267 | for (int i = 0; i < n; i++) { 3268 | foo.acquire(); 3269 | printFoo.run(); 3270 | bar.release(); 3271 | } 3272 | } 3273 | public void bar(Runnable printBar) throws InterruptedException { 3274 | for (int i = 0; i < n; i++) { 3275 | bar.acquire(); 3276 | printBar.run(); 3277 | foo.release(); 3278 | } 3279 | } 3280 | } 3281 | 3282 | ``` 3283 | 3284 | 3285 | 3286 | 3287 | 3288 | 3289 | 3290 | 3291 | 3292 | # **六、个人项目** 3293 | 3294 | ## **一、一站到底** 3295 | 3296 | ​ 采用SpringBoot构建项目，主要通过分布式缓存、队列、限流保证系统高可用，Netty、缓存、反向代理保证高并发。 3297 | 3298 | > 双人对战答题、公司对战抢答 3299 | 3300 | ### 1、如何设计排行榜 3301 | 3302 | - 个人总得分和总排名实时更新 3303 | - 个人排行榜按分数、时间、次数、正确率展示 3304 | - 日榜、过去N日榜滚动更新 3305 | 3306 | #### 性能优化过程 3307 | 3308 | ​ 第一条需求很简单，使用了Redis的**Zset**实现不过这里总得分采用了基于**分数、时间、次数和正确率**的混合加权。考虑到数据的**持久化**，以及**关系数据库和缓存的一致性**导致的设计的复杂性，使用了**谷歌**开源的**JamsRanking** 3309 | 3310 | ​ 优点**是可以直接使用现成的setScores和getRanking接口封装了Redis和Mysql和消息队列的完成**事务和一致性**的使用细节。缺点是**并发比较低**使用Jmeter进行压测，单机只有**20**左右的**TPS** 3311 | 3312 | ​ 后来看了下源码，主要是它针对每一次设置都进行了分布式事务处理，并且会返回事务提交或回滚的结果。了解了底层实现以后就去谷歌的**开源社区**去查阅了相关的解决方案，当时官方对这个问题并没有通过**配置能直接解决问题**的快捷方式，不过推荐了使用者自身如果对响应时间不高的场景下可以采用**批量合并事务**的方式进行优化。基于这个思路，我们把写操作进行了封装并放入了**队列**，然后在消费者端批量取得数据后进行事务的批量处理，压测环境下整体性能达到了**500TPS**。已经基本满足了线上更新的需求，但是当时压测的过程中，队列偶尔的吞吐量会**大范围波动**，经常会持续数十秒，然后业务一次性处理完再响应，导致**局部响应时间大幅度增长** 3313 | 3314 | ​ 后来也是在官网上查询，了解到谷歌开源组件使用的**队列服务**底层是使用**BigTable**作为持久层，但是当BigTable分片过大时，会触发**再分片**的过程，再分片的过程中，是**不会进行任务分发**的，所以就会导致先前的问题。针对这个问题，谷歌官方的建议是提前**配置队列的数量、负载策略和最大容量**等信息，保证所有队列**不同时触发**再分片 3315 | 3316 | ​ 进行两次优化后，压测环境已经基本可以满足预期了，在实际生产环境的部署中，发现对于事务更新失败时，JamsRanking会对失败的事务进行**切分和重试**，整个过程对于研发人员是**透明**的，不利于线上问题排查，所以我们当时特地写了一个watchdog的工具，监控事务回滚达到十次以上的事务，查明原因后通过后台管理系统进行相应补偿，保证**最终一致性** 3317 | 3318 | **最终结果：** 3319 | 3320 | - 高效快速：能在数百毫秒内找到玩家排名以及进行更新 3321 | - 强一致性以及持久化、排名准确 3322 | - 可以扩展到任意数量的玩家 3323 | 3324 | - 吞吐量有限制，只能支持约每秒 500次更新。 3325 | 3326 | 针对这个缺点谷歌官方也是给出了使用分片树和近似排名的解决方案，当然复杂的方案有更高的运维成本，所以我们优化工作也就到此为止 3327 | 3328 | #### 方案优化过程 3329 | 3330 | #### 方案1：每日一个滚动榜，当日汇聚（费时间） 3331 | 3332 | ​ 首先记录每天的排行榜和一个滚动榜，加分时同时写入这两个榜单，每日零点后跑工具将前几天数据累加写入当日滚动榜，该方案缺点是时间复杂度高，7天榜还好，只需要读过去6天数据，如果是100天榜，该方案需要读过去99天榜，显然不可接受 3333 | 3334 | #### 方案2：全局N个滚动榜同时写（费空间） 3335 | 3336 | ​ 要做到每日零点后榜单实时生效，而不需要等待离线作业的完成，一种方案是预写未来的榜单。可以写当天的滚动榜的同时，写往后N-1天的滚动榜一起写入该方案不仅能脱离离线作业做到实时更新，且可以省略每天的日榜。但缺点也不难看出，对于7天滚动榜，每次写操作需要更新7个榜单，但是对于百日榜，空间消耗无法接受，1000万榜单大约消耗1G内存 3337 | 3338 | #### 方案3：实时更新，常数次写操作 3339 | 3340 | 有不有办法做到既能实时更新，写榜数量也不随N的增加而增加呢？ 3341 | 3342 | ​ 仍然是记录每天的排行榜和一个滚动榜，加分操作也还是同时操作当日榜和全局榜，但每日零点的离线作业改为从全局榜中减去之前过期的数据，从而实现先滚动更新。 此方案每次只需读取一个日榜做减法，时间复杂度为O(1)；但是无法做到实时更新。 这个方案的优点是在十二点前提前准备好差分榜，到了十二点直接加上当天数据就是滚动榜内容 ，这样就在常数次写操作的前提下，实现了滚动榜的实时更新 3343 | 3344 | 3345 | 3346 | ### 2、**如何解决重复答题** 3347 | 3348 | ​ **利用setnx防止重复答题** 3349 | ​ 分布式锁是控制分布式系统之间同步访问共享资源的一种方式。 利用Redis的单线程特性对共享资源进行串行化处理 3350 | 3351 | ```java 3352 | // 获取锁推荐使用set的方式 3353 | String result = jedis.set(lockKey, requestId, "NX", "EX", expireTime); 3354 | ``` 3355 | 3356 | ```java 3357 | // 推荐使用redis+lua脚本 3358 | String lua = "if redis.call('get',KEYS[1]) == ARGV[1] then return redis.call('del',KEYS[1]) else return 0 end"; 3359 | Object result = jedis.eval(lua, Collections.singletonList(lockKey) 3360 | ``` 3361 | 3362 | 3363 | 3364 | ### **3、一个题目被多个人抢答** 3365 | 3366 | ​ **利用redis来实现乐观锁（抢答）**，好处是答错的人不影响状态，第一个秒杀答对的人才能得分。 3367 | 3368 | 1、利用redis的watch功能，监控这个 Corp:Activ:Qust: 的状态值 3369 | 2、获取Corp:Activ:Qust: 的值，创建redis事务，给这个key的值-1 3370 | 3、执行这个事务，如果key的值被修改过则回滚，key不变 3371 | 3372 | 3373 | 3374 | ### **4、如何管理昵称重复** 3375 | 3376 | ​ **使用布隆过滤器：** 3377 | 3378 | ​ 它实际上是一个很长的二进制矢量数组和 K 个哈希函数。当一个昵称加入布隆过滤器中的时候，会进行如下操作： 3379 | 3380 | - 使用 K 个哈希函数对元素值进行 K 次计算，得到 K 个哈希值。 3381 | - 根据得到的哈希值，在位数组中把对应下标的值置为 1。 Na 3382 | 3383 | ​ 用户新增昵称时需要首先计算K个哈希值，如果K个哈希值有一个不为0则通过，否则不通过，不通过时通过加随机字符串再次检验，检测通过后返回给前端，帮助用户自动填写。 3384 | 3385 | ​ 布隆过滤器的好处是它**可以用来判断一个元素是否在一个集合中**。它的优势是只需要占用很小的内存空间以及有着高效的查询效率。对于布隆过滤器而言，它的本质是一个**位数组**：位数组就是数组的每个元素都只占用 1 bit ，并且每个元素只能是 0 或者 1。 3386 | 3387 | 3388 | 3389 | BloomFilter 的优势是，全内存操作，性能很高。另外空间效率非常高，**要达到 1% 的误判率，平均单条记录占用 1.2 字节即可。而且，平均单条记录每增加 0.6 字节，还可让误判率继续变为之前的 1/10，即平均单条记录占用 1.8 字节，误判率可以达到 1/1000；平均单条记录占用 2.4 字节，误判率可以到 1/10000，以此类推**。这里的误判率是指，BloomFilter 判断某个 key 存在，但它实际不存在的概率，因为它存的是 key 的 Hash 值，而非 key 的值，所以有概率存在这样的 key，它们内容不同，但多次 Hash 后的 Hash 值都相同。对于 BloomFilter 判断不存在的 key ，则是 100% 不存在的，反证法，如果这个 key 存在，那它每次 Hash 后对应的 Hash 值位置肯定是 1，而不会是 0 3390 | 3391 | ​ 3392 | 3393 | ### **5、如何管理出题定时任务** 3394 | 3395 | ​ 压测环境中服务器通过Netty的主从Reactor多路复用NIO事件模型，单机可以**轻松应对十万长连接**，但是每个业务中，由于每个用户登录系统后需要按照指定顺序答题，例如一共要答十道，那么服务器针对这一个用户就会产生十个定时任务，所以对于系统来说，定时器的**数量就是百万级别的**。 3396 | 3397 | ​ 通过压测结果发现：JDK自带的Timer，在大概三万并发时性能就急剧下降了。也是此时根据业务场景的需要，将定时任务改成了Netty自带的HashedWheelTimer时间轮方案，通过压测单机在50万级别下依然能够平滑的执行。 3398 | 3399 | ​ 也是这个强烈的反差，使我在强烈的好奇心促使下，阅读源码了解到常规的JDK 的Timer 和 DelayedQueue 等工具类，可实现简单的定时任务，单底层用的是**堆数据结构**，存取复杂度都是 **O(NlogN)**，无法支撑海量定时任务。**Netty经典的时间轮方案**，正是通过将任务存取及取消操作时间复杂度降为 O(1)，而广泛应用在定时**任务量大、性能要求高**的场景中。 3400 | 3401 | ​ img 3402 | 3403 | ​ 基于Netty的Websocket底层，服务器端维护一个高效批量管理定时任务的调度模型。时间轮一般会实现成一个**环形数组结构**，类似一个时钟，分为很多槽，一个槽代表一个时间间隔，每个槽使用**双向链表**存储定时任务。指针**周期性地跳动**，跳动到一个槽位，就执行该槽位的定时任务。 3404 | 3405 | ​ 单层时间轮的容量和精度都是有限的，对于精度要求特别高、时间跨度特别大或是海量定时任务需要调度的场景，可以考虑使用多级时间轮以及持久化存储与时间轮结合的方案。时间轮的**定时任务处理逻辑**如下： 3406 | 3407 | 1. 将缓存在 timeouts 队列中的定时任务转移到时间轮中对应的槽中 3408 | 2. 根据当前指针定位对应槽，处理该槽位的双向链表中的定时任务，从链表头部开始迭代： 3409 | - 属于当前时钟周期则取出运行 3410 | - 不属于则将其剩余的时钟周期数减一 3411 | 3. 检测时间轮的状态。如果时间轮处于运行状态，则循环执行上述步骤，不断执行定时任务。 3412 | 3413 | 3414 | 3415 | ### **6：如何解决客户端断连** 3416 | 3417 | ​ 使用Netty的**重连检测狗**ConnectionWatchdog 3418 | 3419 | ​ 服务端定义refreshTime，当我们从channel中read到了服务端发来的心跳响应消息的话，就刷新refreshTime为当前时间 3420 | 3421 | ​ 客户端在state是WRITER_IDLE的时候每隔一秒就发送一个心跳包到sever端，告诉server端我还活着。 3422 | 3423 | 当重连成功时，会触发channelActive方法，在这里我们开启了一个定时任务去判断refreshTime和当前时间的时间差，超过5秒说明断线了，要进行重连，最后计算重连次数，尝试连接2次以上连不上就会修改header信息强制重连去连另一个服务器。 3424 | 3425 | 3426 | 3427 | 3428 | 3429 | ## 二、秒杀项目 3430 | 3431 | ### **技术选型** 3432 | 3433 | 秒杀用到的基础组件，主要有**框架、KV 存储、关系型数据库、MQ**。 3434 | 3435 | 框架主要有 Web 框架和 RPC 框架。 3436 | 3437 | 其中，Web 框架主要用于提供 HTTP 接口给浏览器访问，所以 Web 框架的选型在秒杀服务中非常重要。在这里，我**推荐Gin**，它的性能和易用性都不错，在 **GitHub 上的 Star 达到了 44k**。对比性能最好的 fasthttp，虽然 fasthttp 在请求延迟低于 10ms 时性能优势明显，但其底层使用的对象池容易让人踩坑，导致其易用性较差，所以没必要过于追求性能而忽略了稳定性 3438 | 3439 | 至于 RPC 框架，我推荐选用 **gRPC**，因为它的扩展性和性能都非常不错。在秒杀系统中，Redis 中的数据主要是给秒杀接口服务使用，以便将配置从管理后台同步到 Redis 缓存中。 3440 | 3441 | KV 存储方面，秒杀系统中主要是用 **Redis 缓存活动配置**，用 **etcd 存储集群信息**。 3442 | 3443 | 关系型数据库中，**MySQL** 技术成熟且稳定可靠，秒杀系统用它存储活动配置数据很合适。主要 原因还是秒杀活动信息和库存数据都缓存在 Redis 中，活动过程中秒杀服务不操作数据库， 使用 MySQL 完全能够满足需求。 3444 | 3445 | MQ 有很多种，其中 **Kafka** 在业界认可度最高，技术也非常成熟，性能很不错，非常适合用在秒杀系统中。Kafka 支持自动创建队列，秒杀服务各个节点可以用它自动创建属于自己的队列 3446 | 3447 | 3448 | 3449 | ### 方案设计 3450 | 3451 | **背景** 3452 | 3453 | - 秒杀业务简单，每个秒杀活动的商品是事先定义好的，商品有明确的类型和数量，卖完即止 3454 | - 3455 | 秒杀活动定时上架，消费者可以在活动开始后，通过秒杀入口进行抢购秒杀活动 3456 | 3457 | - 3458 | 秒杀活动由于商品物美价廉，开始售卖后，会被快速抢购一空。 3459 | 3460 | 3461 | **现象** 3462 | 3463 | - 3464 | 秒杀活动持续时间短，访问冲击量大，秒杀系统需要应对这种爆发性的访问模型 3465 | 3466 | - 3467 | 业务的请求量远远大于售卖量，大部分是陪跑的请求，秒杀系统需要提前规划好处理策略 3468 | 3469 | - 3470 | 前端访问量巨大，系统对后端数据的访问量也会短时间爆增，对数据存储资源进行良好设计 3471 | 3472 | - 3473 | 活动期间会给整个业务系统带来超大负荷，需要制定各种策略，避免系统过载而宕机 3474 | 3475 | - 3476 | 售卖活动商品价格低廉，存在套利空间，各种非法作弊手段层出，需要提前规划预防策略 3477 | 3478 | 3479 | **秒杀系统设计** 3480 | 3481 | 3482 | ​ 首先，要**尽力将请求拦截在系统上游**，层层设阻拦截，过滤掉无效或超量的请求。因为访问量远远大于商品数量，所有的请求打到后端服务的最后一步，其实并没有必要，反而会严重拖慢真正能成交的请求，降低用户体验。 3483 | 3484 | ​ 秒杀系统专为秒杀活动服务，售卖商品确定，因此可以在设计秒杀商品页面时，将商品信息提前设计为静态信息，将静态的商品信息以及常规的 CSS、JS、宣传图片等静态资源，一起**独立存放到 CDN 节点**，加速访问，且降低系统访问压力，在访问前端也可以**制定种种限制策略，**比如活动没开始时，抢购按钮置灰，避免抢先访问，用户抢购一次后，也将按钮置灰，让用户排队等待，避免反复刷新。 3485 | 3486 | ​ 其次，要**充分利用缓存**，提升系统的性能和可用性。 3487 | 3488 | 3489 | ​ 用户所有的请求进入秒杀系统前，通过**负载均衡策略**均匀分发到不同 Web 服务器，避免节点过载。在 Web 服务器中，首先检查用户的访问权限，识别并发刷订单的行为。如果发现售出数量已经达到秒杀数量，则直接返回结束，要将秒杀业务系统和其他业务系统进行功能分拆，尽量将秒杀系统及依赖服务**独立分拆部署**，避免影响其他核心业务系统。 3490 | 3491 | 3492 | ​ 秒杀系统需要构建访问记录缓存，记录访问 IP、用户的访问行为，发现异常访问，提前进行阻断及返回。同时还需要**构建用户缓存**，并针对历史数据分析，提前缓存僵尸强刷专业户，方便在秒杀期间对其进行策略限制。这些访问记录、用户数据，通过缓存进行存储，可以加速访问，另外，对用户数据还进行缓存预热，避免活动期间大量穿透。 3493 | 3494 | 3495 | 3496 | 3497 | 3498 | ### **1、如何解决超卖？** 3499 | 3500 | mysql乐观锁+redis预减库存+redis缓存卖完标记 3501 | 3502 | 3503 | 3504 | 第一是基于**数据库乐观锁**的方式保证数据并发扣减的强一致性； 3505 | 3506 | 第二是基于**数据库的事务**实现批量扣减部分失败时的数据回滚。 3507 | 3508 | ​ 在扣减指定数量前应先做一次前置数量校验的读请求（参考**读写分离** + **全缓存方案**） 3509 | 3510 | 3511 | 3512 | > 纯数据库乐观锁+事务的方式性能比较差，但是如果不计成本和考虑场景的话也完全够用，因为任何没有机器配置的指标，都是耍流氓。如果我采用 Oracle 的数据库、100 多核的刀锋服务器、SSD 的硬盘，即使是纯数据库的扣减方案，也是可以达到单机上万的 TPS 的。 3513 | 3514 | 3515 | 3516 | **单线程Redis 的 lua 脚本实现批量扣减** 3517 | 3518 | 当用户调用扣减接口时，将扣减的 对应数量 + 脚本标示传递至 Redis 即可，所有的扣减判断逻辑均在 Redis 中的 lua 脚本中执行，lua 脚本执行完成之后返还是否成功给客户端。 3519 | 3520 | image-20210504174103769 3521 | 3522 | Redis 中的 lua 脚本执行时，首先会使用 get 命令查询 uuid 进行查重。当防重通过后，会**批量获取对应的剩余库存状态并进行判断**，如果一个扣减的数量大于剩余数量，则返回错误并提示数量不足。 3523 | 3524 | Redis 的单线程模型，确保**不会出现当所有扣减数量在判断均满足后，在实际扣减时却数量不够**。同时，单线程保证判断数量的步骤和后续扣减步骤之间，没有其他任何线程出现并发的执行。 3525 | 3526 | 当 Redis 扣减成功后，扣减接口会**异步的将此次扣减内容保存至数据库**。异步保存数据库的目的是防止出现极端情况—— Redis 宕机后数据未持久化到磁盘，此时我们可以使用数据库恢复或者校准数据 3527 | 3528 | 最后，运营后台直连数据库，是运营和商家修改库存的入口。商家在运营后台进货物进行补充。同时，运营后台的实现需要将此数量**同步的增加至 Redis**，因为当前方案的所有实际扣减都在 Redis 中 3529 | 3530 | 3531 | 3532 | > 纯缓存方案虽**不会导致超卖**，但因**缓存不具备事务特性**，极端情况下会存在缓存里的数据**无法回滚**，导致出现**少卖**的情况。且架构中的异步写库，也可能发生失败，导致多扣的数据丢失 3533 | 3534 | 3535 | 3536 | 可以借助**顺序写**的特性，将扣减任务同步**插入**任务表，发现异常时，将任务表作为**undolog**进行回滚 3537 | 3538 | 可以解决由于**网络不通**、调用缓存**扣减超时**、在扣减到一半时缓存**突然宕机**（故障 failover）了。针对上述请求，都有相应的异常抛出，根据异常进行**数据库回滚**即可，最终任务库里的数据都是准的 3539 | 3540 | 3541 | 3542 | 更进一步：由于任务库是无状态的，可以进行水平分库，提升整体性能 3543 | 3544 | 3545 | 3546 | ### **2、如何解决重复下单？** 3547 | 3548 | mysql唯一索引+分布式锁 3549 | 3550 | 3551 | 3552 | ### **3、如何防刷？** 3553 | 3554 | IP限流 | 验证码 | 单用户 | 单设备 | IMEI | 源IP |均设置规则 3555 | 3556 | 3557 | 3558 | ### **4、热key问题如何解决？** 3559 | 3560 | redis集群+本地缓存+限流+key加随机值分布在多个实例中 3561 | 3562 | 1、**缓存集群**可以单节点进行**主从复制和垂直扩容** 3563 | 3564 | 2、利用应用内的**前置缓存**，但是需注意需要设置上限 3565 | 3566 | 3、延迟不敏感，**定时刷新**，实时感知用主动刷新 3567 | 3568 | 4、和缓存穿透一样，限制逃逸流量，单请求进行数据**回源并刷新前置** 3569 | 3570 | 5、无论如何设计，最后都要写一个**兜底逻辑**，千万级流量说来就来 3571 | 3572 | 3573 | 3574 | ### **5、应对高并发的读请求** 3575 | 3576 | 使用缓存策略将请求挡在上层中的缓存中 3577 | 3578 | 使用CDN，能静态化的数据尽量做到静态化， 3579 | 3580 | 加入限流（比如对短时间之内来自某一个用户，某一个IP、某个设备的重复请求做丢弃处理） 3581 | 3582 | **资源隔离限流**会将对应的资源按照指定的类型进行隔离，比如**线程池**和**信号量**。 3583 | 3584 | - 计数器限流，例如5秒内技术1000请求，超数后限流，未超数重新计数 3585 | 3586 | - 滑动窗口限流，解决计数器不够精确的问题，把一个窗口拆分多滚动窗口 3587 | 3588 | - 令牌桶限流，类似景区售票，售票的速度是固定的，拿到令牌才能去处理请求 3589 | 3590 | - 漏桶限流，生产者消费者模型，实现了恒定速度处理请求，能够绝对防止突发流量 3591 | 3592 | 流量控制效果从好到差依次是：**漏桶限流 > 令牌桶限流 > 滑动窗口限流 > 计数器限流** 3593 | 3594 | image-20210504174148831 3595 | 3596 | 其中，只有漏桶算法**真正实现了恒定速度处理请求**，能够绝对**防止突发流量超过下游系统承载能力**。 3597 | 不过，漏桶限流也有个不足，就是需要分**配内存资源缓存请求**，这会增加内存的使用率。而**令牌桶限流**算法中的“桶”可以用一个整数表示，**资源占用相对较小**，这也让它成为最常用的限流算法。正是因为这些特点，**漏桶限流和令牌桶限流**经常在一些大流量系统中结合使用。 3598 | 3599 | 3600 | 3601 | ### **6、应对高并发的写请求** 3602 | 3603 | - **削峰**：恶意用户拦截 3604 | 3605 | 对于单用户多次点击、单设备、IMEI、源IP均设置规则 3606 | 3607 | - 采用比较成熟的**漏桶算法、令牌桶**算法，也可以使用**guava**开箱即用的限流算法 3608 | 3609 | 可以集群限流，但单机限流更加简洁和稳定 3610 | 3611 | - 当前层**直接过滤**一定比例的请求，最大承载值前需要加上**兜底逻辑** 3612 | 3613 | - 对于已经无货的产品，**本地缓存**直接返回 3614 | 3615 | - **单独部署，减少对系统正常服务的影响，方便扩缩容** 3616 | 3617 | 3618 | 3619 | 对于**一段时间内的秒杀活动，需要保证写成功**，我们可以使用 **消息队列**。 3620 | 3621 | - 削去秒杀场景下的峰值写流量——**流量削峰** 3622 | - 通过异步处理简化秒杀请求中的业务流程——**异步处理** 3623 | - 解耦，实现秒杀系统模块之间松耦合——**解耦** 3624 | 3625 | **削去秒杀场景下的峰值写流量** 3626 | 3627 | - **将秒杀请求暂存于消息队列**，业务服务器响应用户“秒杀结果正在处理中。。。”，释放系统资源去处理其它用户的请求。 3628 | - **削峰填谷**，削平短暂的流量高峰，消息堆积会造成请求延迟处理，但秒杀用户对于短暂延迟有一定容忍度。秒杀商品有 1000 件，处理一次购买请求的时间是 500ms，那么总共就需要 500s 的时间。这时你部署 10 个队列处理程序，那么秒杀请求的处理时间就是 50s，也就是说用户需要等待 50s 才可以看到秒杀的结果，这是可以接受的。这时会**并发 10 个**请求到达数据库，并不会对数据库造成很大的压力。 3629 | 3630 | **通过异步处理简化秒杀请求中的业务流程** 3631 | 3632 | ​ 先处理主要的业务，异步处理次要的业务。 3633 | 3634 | - 如主要流程是**生成订单**、**扣减库存**； 3635 | - 次要流程比如购买成功之后会给用户**发优惠券**，**增加用户的积****分**。 3636 | - 此时秒杀只要处理生成订单，扣减库存的耗时，发放优惠券、增加用户积分异步去处理了。 3637 | 3638 | **解耦** 3639 | 3640 | ​ 实现秒杀系统模块之间松耦合将秒杀数据同步给数据团队，有两种思路： 3641 | 3642 | - 使用 HTTP 或者 RPC 同步调用，即提供一个接口，实时将数据推送给数据服务。**系统的耦合度高**，如果其中一个服务有问题，可能会导致另一个服务不可用。 3643 | - 使用消息队列**将数据全部发送给消息队列**，然后**数据服务订阅这个消息队列**，接收数据进行处理。 3644 | 3645 | 3646 | 3647 | 3648 | 3649 | ### **7、如何保证数据一致性** 3650 | 3651 | **CacheAside旁路缓存**读请求不命中查询数据库，查询完成写入缓存，写请求更新数据库后删除缓存数据。 3652 | 3653 | ```java 3654 | // 延迟双删，用以保证最终一致性,防止小概率旧数据读请求在第一次删除后更新数据库 3655 | public void write(String key,Object data){ 3656 | redis.delKey(key); 3657 | db.updateData(data); 3658 | Thread.sleep(1000); 3659 | redis.delKey(key); 3660 | } 3661 | ``` 3662 | 3663 | 为防缓存失效这一信息丢失，可用消息队列确保。 3664 | 3665 | - 更新数据库数据； 3666 | - 数据库会将操作信息写入binlog日志当中； 3667 | - 另起一段非业务代码，程序订阅提取出所需要的数据以及key； 3668 | - 尝试删除缓存操作，若删除失败，将这些信息发送至消息队列； 3669 | - 重新从消息队列中获得该数据，重试操作； 3670 | 3671 | 订阅**binlog程序在mysql中有现成的中间**件叫canal，重试机制，主要采用的是消息队列的方式。 3672 | 3673 | 3674 | 3675 | **终极方案：请求串行化** 3676 | 3677 | 真正靠谱非秒杀的方案：将访问操作串行化 3678 | 3679 | 1. 先删缓存，将更新数据库的**写操作放进有序队列中** 3680 | 2. 从缓存查不到的**读操作也进入有序队列** 3681 | 3682 | 需要解决的问题： 3683 | 3684 | 1. 读请求积压，大量超时，导致数据库的压力：限流、熔断 3685 | 2. 如何避免大量请求积压：将队列水平拆分，提高并行度。 3686 | 3687 | 3688 | 3689 | 3690 | 3691 | ### 8、可靠性如何保障** 3692 | 3693 | ​ 由一个或多个sentinel实例组成sentinel集群可以监视一个或多个主服务器和多个从服务器。**哨兵模式适合读请求远多于写请求的业务场景，比如在秒杀系统**中用来缓存活动信息。 如果写请求较多，当集群 Slave 节点数量多了后，Master 节点同步数据的压力会非常大。 3694 | 3695 | image-20201220231241725 3696 | 3697 | ​ 当主服务器进入下线状态时，sentinel可以将该主服务器下的某一从服务器升级为主服务器继续提供服务，从而保证redis的高可用性。 3698 | 3699 | 3700 | 3701 | ### 9、秒杀系统瓶颈-日志 3702 | 3703 | > 秒杀服务单节点需要处理的请求 QPS 可能达到 10 万以上。一个请求从进入秒杀服务到处理失败或者成功，至少会产生两条日志。也就是说，高峰期间，一个秒杀节点每秒产生的日志可能达到 **30 万条**以上 3704 | 3705 | ​ 一块性能比较好的固态硬盘，每秒写的IOPS 大概在 3 万左右。也就是说，一个秒杀节点的每秒日志条数是固态硬盘 IOPS 的 10 倍，磁盘都扛不住，更别说通过网络写入到监控系统中。 3706 | 3707 | - **每秒日志量远高于磁盘 IOPS**，直接写磁盘会影响服务性能和稳定性 3708 | - 大量日志导致服务频繁分配，**频繁释放内存，影响服务性能**。 3709 | - 服务异常退出**丢失大量日志**的问题 3710 | 3711 | **解决方案** 3712 | 3713 | - **Tmpfs**，即临时文件系统，它是一种基于内存的文件系统。我们可以将秒杀服务写日志的文件放在临时文件系统中。相比直接写磁盘，在临时文件系统中写日志的性能至少**能提升 100 倍**，每当日志文件达到 20MB 的时候，就将**日志文件转移到磁盘上**，并将临时文件系统中的日志文件清空。 3714 | - 可以参考内存池设计，将给logger分配缓冲区，每一次的新写可以复用Logger对象 3715 | - 参考kafka的缓冲池设计，当缓冲区达到大小和间隔时长临界值时，调用Flush函数，减少丢失的风险 3716 | 3717 | 3718 | 3719 | **10、池化技术** 3720 | 3721 | ![image-20210504174220668](https://tva1.sinaimg.cn/large/008i3skNly1gq6japwof2j31520na4mh.jpg) 3722 | 3723 | ​ 通常可以采用**循环队列**来保存空闲连接。使用的时候，可以从队列头部取出连接，用完后将空闲连接放到队列尾部。Netty中利用带缓冲区的 channel 来充当队列。 3724 | 3725 | 3726 | 3727 | ## 三、即时通信 3728 | 3729 | 3730 | 3731 | ### 1、**单聊消息可靠传输** 3732 | 3733 | TCP保证消息可靠传输三板斧：超时、重传、确认。服务端和客户端通信MSG和ACK的共计6个报文 3734 | 3735 | - 请求报文（request，后简称为为R），客户端主动发送给服务端。 3736 | - 应答报文（acknowledge，后简称为A），服务器被动应答客户端的报文。 3737 | - 通知报文（notify，后简称为N），服务器主动发送给客户端的报文 3738 | 3739 | **在线消息流程：** 3740 | 3741 | ​ A 消息请求 **MSG:R** => S 消息应答 **MSG:A** => S 消息通知B **MSG:N** 3742 | 3743 | ​ S 确认通知 **ACK:N** <= S 确认应答 **ACK:A** <= B确认请求S **ACK:R** 3744 | 3745 | **超时与重传、确认和去重：** 3746 | 3747 | ​ A发出了 **MSG:R** ，收到了**MSG:A**之后，在一个期待的时间内，如果没有收到**ACK:N**，A会尝试将 **MSG:R** 重发。可能A同时发出了很多消息，所以A需要在本地维护一个等待ack队列，并配合timer超时机制，来记录哪些消息没有收到**ACK:N**，定时重发。确认ACK**保证必达**，去重保证**唯一** 3748 | 3749 | **离线消息流程** 3750 | 3751 | ​ 原方案：根据离线好友的标识，交互拉取指定的消息 3752 | 3753 | ![IM消息送达保证机制实现(二)：保证离线消息的可靠投递_2.png](https://tva1.sinaimg.cn/large/0081Kckwly1gm8kxci29zj30b305974z.jpg) 3754 | 3755 | 优化的方案： 3756 | 3757 | - 如用户**勾选全量**则返回计数，在用户点击时拉取。 3758 | - 如用户未勾选全量则返回**最近全部离线消息**，客户端针对**用户id进行计算**。 3759 | - 全量离线信息可以通过客户端异步线程分页拉取，减少卡顿 3760 | - 将ACK和分页第二次拉取的报文重合，可以较少离线消息拉取交互的次数 3761 | 3762 | 3763 | 3764 | ### **2、群聊消息如何保证不丢不重** 3765 | 3766 | > 在线的群友能第一时间收到消息； 3767 | > 离线的群友能在登陆后收到消息。 3768 | 3769 | 3770 | 3771 | ![IM群聊消息如此复杂，如何保证不丢不重？_1.jpg](https://tva1.sinaimg.cn/large/0081Kckwly1gm8jswr3poj30hh078dg2.jpg) 3772 | 3773 | - 群消息发送者x向server发出群消息； 3774 | - server去db中查询群中有多少用户(x,A,B,C,D)； 3775 | - server去cache中查询这些用户的在线状态； 3776 | - 对于群中在线的用户A与B，群消息server进行实时推送； 3777 | - 对于群中离线的用户C与D，群消息server进行离线存储。 3778 | 3779 | ​ 对于同一份群消息的内容，多个离线用户存储了很多份。假设群中有200个用户离线，离线消息则冗余了200份，这极大的增加了数据库的存储压力 3780 | 3781 | - 离线消息表只存储用户的群离线消息msg_id，降低数据库的冗余存储量 3782 | - 加入应用层的ACK，才能保证群消息一定到达，服务端幂等性校验及客户端去重，保证不重复 3783 | - 每条群消息都ACK，会给服务器造成巨大的冲击，通过批量ACK减少消息风暴扩散系数的影响 3784 | 3785 | - 群离线消息过多：拉取过慢，可以通过分页懒拉取改善。 3786 | 3787 | 3788 | 3789 | ### 3、**如何保证消息的时序性** 3790 | 3791 | 方案： 3792 | 3793 | - Id通过借鉴微信号段+跳跃的方式保证趋势递增 3794 | - 单聊借鉴数据库设计，单点序列化同步到其他节点保证多机时序 3795 | - 群聊消息使用单点序列化保证各个发送者的消息相对时序 3796 | 3797 | ![如何保证IM实时消息的“时序性”与“一致性”？_10.jpg](https://tva1.sinaimg.cn/large/0081Kckwly1gm8m1ge2ksj30j707gt96.jpg) 3798 | 3799 | 优化： 3800 | 3801 | - 利用服务器单点序列化时序，可能出现服务端收到消息的时序，与发出序列不一致 3802 | - 在A往B发出的消息中，加上发送方A本地的一个绝对时序，来表示接收方B的展现时序。 3803 | - 群聊消息保证一个群聊落在一个service上然后通过本地递增解决全局递增的瓶颈问题 3804 | 3805 | 3806 | 3807 | ### **4：推拉结合** 3808 | 3809 | 历史方案： 3810 | 3811 | - 服务器在缓存集群里存储所有用户的在线状态 -> 保证状态可查 3812 | - 用户状态实时变更，任何用户登录/登出时，需要推送所有好友更新状态 3813 | - A登录时，先去数据库拉取自己的好友列表，再去缓存获取所有好友的在线状态 3814 | 3815 | **“消息风暴扩散系数”**是指一个消息发出时，变成N个消息的扩散系数，这个系数与业务及数据相关，一定程度上它的大小决定了技术采用推送还是拉取。 3816 | 3817 | 优化方案： 3818 | 3819 | - **好友状态推拉结合**，首页置顶亲密、当前群聊，采用推送，否则可以采用轮询拉取的方式同步； 3820 | - **群友的状态**，由于消息风暴扩散系数过大，可以采用按需拉取，延时拉取的方式同步； 3821 | - **系统消息/开屏广告等**这种实时产生的消息，可以采用推送的方式获取消息； 3822 | 3823 | 3824 | 3825 | ### 5、好友推荐 3826 | 3827 | Neo4j 图谱数据库 3828 | 3829 | 3830 | 3831 | 3832 | 3833 | ## 四、智慧社区 3834 | 3835 | ​ 18年初，针对我们Dubbo框架的智慧楼宇项目的单体服务显得十分笨重，需要采用微服务的形式进行架构的重新设计，当时，我阅读了*Eric Evans* 写的《领域驱动设计：软件核心复杂性应对之道》和*Martin* *fowler*的《微服务架构：*Microservice*》两本重量级书籍，书中了解到转型微服务的重要原因之一就是利用**分治的思想**减少系统的复杂性，是一种针对**复杂问题的宏观设计**，来应对系统后来规模越来越大，维护越来越困难的问题。然而，拆分成微服务以后，并**不意味着每个微服务都是各自独立地运行**，而是彼此协作地组织在一起。这就好像一个团队，**规模越大越需要一些方法来组织**，这正是我们需要DDD模型为我们的架构设计提供理论并实践的方法。 3836 | 3837 | ​ 当时每次版本更新迭代动辄十几个微服务同时修改，有时一个简单的数据库字段变更，也需要同时变更多个微服务，引起了团队的反思：微服务化看上去并没有减少我们的工作量。《企业架构设计》中对于微服务的定义是**小而专**，但在起初的设计时，我们只片面的**理解了小却忽视了专**，此时我们才意识到拆分的关键是要保证微服务内高内聚，微服务间低耦合。 3838 | 3839 | ### **物联网架构** 3840 | 3841 | > 物联网是互联网的**外延**。将用户端**延伸**和扩展到物与人的连接。物联网模式中，所有**物品与网络连接**，并进行通信和场景联动。互联网通过**电脑、移动终端**等设备将参与者联系起来，形成的一种全新的**信息互换方式** 3842 | 3843 | #### DCM系统架构 3844 | 3845 | - **设备感知层**（Device）：利用射频识别、二维码、传感器等技术进行数据采集 3846 | - **网络传输层**（Connect）：依托通信网络和协议，实现可信的信息交互和共享 3847 | - **应用控制层**（Manage）：分析和处理海量数据和信息，实现智能化的决策和控制 3848 | 3849 | image-20210504174337327 3850 | 3851 | #### **三要素** 3852 | 3853 | - **设备联网**：通过不同的网络协议和通信标准，实现设备与控制端的连接 3854 | - **云端分析**：提供监控、存储、分析等数据服务，以及保障客户的业务数据安全 3855 | - **云边协同**：云端接受设备上报数据，下发设备管控指令 3856 | 3857 | #### 云 / 边 / 端协同 3858 | 3859 | **云端计算**、**终端计算**和**边缘计算**是一个协同的系统，根据用户场景、资源约束程度、业务实时性等进行动态调 配，形成可靠、低成本的应用方案。从过去几年的发展积累来看，AI 已在物联网多个层面进行融合，比我们合作的海康威视、旷视宇视、商汤科技等纷纷发布了物联网AI相关平台和产品，和移动和小区进行了紧密的融合。 3860 | 3861 | image-20210202225351673 3862 | 3863 | 3864 | 3865 | #### 物联网平台接入 3866 | 3867 | 企业基于物联网平台的业务链路 3868 | 3869 | 向下连接海量设备，支撑设备**数据采集上云**； 3870 | 3871 | 向上通过调用**云端API**将指令下发至设备端，实现**远程控制**。 3872 | 3873 | 3874 | 3875 | **上行数据链路** 3876 | 3877 | - 设备建立**MQTT**长连接，上报数据（发布Topic和Payload）到物联网平台 3878 | - 物联网平台通过**配置**规则，通过**RocketMQ**、**AMQP**等队列转发到业务平台 3879 | 3880 | **下行指令链路** 3881 | 3882 | - 业务服务器基于**HTTPS**协议调用的API接口，发布Topic指令到物联网平台。 3883 | - 物联网平台通过**MQTT**协议，使用发布（指定Topic和Payload）到**设备端**。 3884 | 3885 | 3886 | 3887 | #### 门锁接入 3888 | 3889 | **WIFI门锁**：**非保活** 平常处于断电休眠状态，需要**MCU** **唤醒**才能传输和发送数据 3890 | 3891 | **蓝牙门锁**：**MCU串口对接**和**SDK对接**，近距离**单点登录**和远距离**网关登录** 3892 | 3893 | **Zigbee门锁**：**非保活** 但是保持心跳，**MCU**对接，**Zigbee协议**控制。 3894 | 3895 | **NB-Iot门锁**：可以通过**公网**连接，把门禁变成**SAAS**服务，**MCU** 3896 | 3897 | | 名词 | 解释 | 3898 | | -------- | ------------------------------------------------------------ | 3899 | | **SaaS** | **Software-as-a-Service** ，提供给客户的服务是运营商运行在云计算基础设施上的应用程序。**用户可以在各种设备上通过客户端界面访问应用**，例如计算机浏览器。用户不需要管理或控制任何云计算基础设施，包括网络、服务器、操作系统、存储等资源，一切由 SaaS 提供商管理和运维。 | 3900 | | **PaaS** | **Platform-as-a-Service**，表示平台即服务理念，客户不需要管理或控制底层的云基础设施，包括网络、服务器、操作系统、存储等，但**客户能控制部署的应用程序**，也可能控制运行应用程序的托管环境配置。 | 3901 | | **IaaS** | I**nfrastructure-as-a-Service** ，表示基础设施即服务理念，提供的服务是对所有计算基础设施的利用，包括 CPU、内存、存储、网络等其它计算资源。**用户能够部署和运行任意软件，包括操作系统和应用程序。** | 3902 | 3903 | 3904 | 3905 | #### 各种协议 3906 | 3907 | **HTTP协议（CS用户上网）** 3908 | 3909 | HTTP协议是典型的CS通讯模式，由**客户端主动**发起连接，向服务器请求**XML或JSON数据**。该协议最早是为了适用web浏览器的**上网浏览场景**和设计的，目前在**PC、手机、pad**等终端上都应用广泛，但并**不适用于物联网场景** 3910 | 3911 | - 由于必须由设备主动向服务器发送数据，难以主动向设备推送数据。 3912 | - 物联网场景中的**设备多样**，运算**受限的设备**，难以实现JSON数据格式的解析 3913 | 3914 | **RESTAPI（松耦合调用）** 3915 | 3916 | REST/HTTP主要为了**简化**互联网中的系统架构，**快速实现**客户端和服务器之间交互的**松耦合**，降低了客户端和服务器之间的**交互延迟**。因此适合在物联网的应用层面，通过REST**开放**物联网中资源，实现服务被其他应用所调用。 3917 | 3918 | **CoAP协议（无线传感）** 3919 | 3920 | > 简化了HTTP协议的**RESTful API**，它适用于在**资源受限**的通信的IP网络。 3921 | 3922 | **MQTT协议（低带宽）** 3923 | 3924 | > MQTT协议采用**发布/订阅**模式，物联网终端都通过TCP连接到云端，云端通过主题的方式管理各个设备关注的通讯内容，**负责**将设备与设备之间**消息的转发** 3925 | 3926 | 适用范围：在低带宽、不可靠的集中**星型网络架构**（hub-and-spoke），不适用设备与设备之间通信，设备**控制能力弱**，另外**实时性较差**，一般都在**秒级**。协议要**足够轻量**，方便嵌入式设备去快速地解析和响应。具备**足够的灵活性**，使其足以为 IoT 设备和服务的多样化提供支持。应该设计为**异步消息协议**，这么做是因为大多数 IoT 设备的网络延迟很可能非常不稳定，若使用同步消息协议，IoT 设备需要等待服务器的响应，必须是**双向通信**，服务器和客户端应该可以互相发送消息。 3927 | 3928 | **AMQP协议（互操作性）** 3929 | 3930 | > 用于业务系统例如PLM，ERP，MES等进行数据交换。 3931 | 3932 | 　　适用范围：最早应用于金融系统之间的交易消息传递，在物联网应用中，主要适用于移动手持设备与后台数据中心的通信和分析。 3933 | 3934 | **XMPP协议（即时通信）** 3935 | 3936 | > 开源形式组织产生的网络即时通信协议。被IETF国际标准组织完成了标准化工作 3937 | 3938 | 　　适用范围：**即时通信**的应用程序，还能用在**协同工具**、游戏等。 3939 | 3940 | ​ XMPP在通讯的业务流程上是更适合物联网系统的，开发者不用花太多心思去解决设备通讯时的业务通讯流程，相对开发成本会更低。但是HTTP协议中的安全性以及计算资源消耗的硬伤并没有得到本质的解决。 3941 | 3942 | **JMS （Java消息服务）** 3943 | 3944 | ​ Java消息服务（Java Message Service）应用程序接口，是一个Java平台中关于面向消息中间件（MOM）的API，用于在两个应用程序之间，或分布式系统中发送消息，进行异步通信。 3945 | 3946 | **Zigbee协议** 3947 | 3948 | ​ 低功耗，它保持IEEE 802.15.4（2003）标准 3949 | 3950 | ### IOT流量洪峰 3951 | 3952 | 智慧社区IOT领域，不管是嵌入式芯片还是应用服务器都需要传递消息，常见上行的消息有：**人脸识别开门、烟感雾感告警**、共享充电桩充电，下行的**广告下发、NB门禁开门指令、**超级门板显示等，由于物联网设备时不时会**故障和断网导致大量的流量洪峰**，传统消息队列需要针对性优化。 3953 | 3954 | - **上下行拆分** 3955 | 3956 | 上行消息特征：并发量**高**、可靠性和**时延性要求低** 3957 | 3958 | 下行消息特征：并发量**低**、控制指令的**成功率要求高** 3959 | 3960 | - **海量Topic下性能** 3961 | 3962 | **Kafka**海量Topic性能会**急剧下降**，Zookeeper协调也有瓶颈 3963 | 3964 | **多泳道消息队列**可以实现IoT消息队列的故障**隔离** 3965 | 3966 | - **实时消息优先处理** 3967 | 3968 | NB门禁实时产生的开门指令必须**第一优先级处理**，堆积的消息降级 3969 | 3970 | 设计成**无序、不持久化**的，并与传统的FIFO队列隔离 3971 | 3972 | - **连接、计算、存储分离** 3973 | 3974 | Broker只做**流转分发**，实现**无状态**和**水平扩展** 3975 | 3976 | 计算交给**Flink**，存储交给nosqlDB，实现**高吞吐写** 3977 | 3978 | - **消息策略-推拉结合** 3979 | 3980 | MQTT针对电池类物联网设备，AMQP针对安全性较高的门禁设备 3981 | 3982 | 消费端离线时存到queue，在线时将**实时消息和从queue中拉取的消息**一起推送 3983 | 3984 | ![img](https://tva1.sinaimg.cn/large/008eGmZEly1goboitd4h2j30u00ciq3i.jpg) 3985 | 3986 | **如果解决海量Topic** 3987 | 3988 | ​ 首先要做的就是分区、分组等水平拆分的方式，接下来考虑单实例如何处理更多Topic，传统消息队列在海量Topic下顺序写会退化成随机写，性能大幅下降 3989 | 3990 | - **人工Sharding**：部署多个Kafka集群，通过不同mq连接来隔离 3991 | 3992 | - **合并Topic**，客户端封装subTopic。比如一个服务的N个统计项，会消费到无关消息 3993 | 3994 | ​ 基于这个思路，使用**Kafka Streams**或者**Hbase列**存储来聚合 3995 | 3996 | 针对单个Topic海量订阅的问题，**可以在上层封装广播组件来协调批量发送** 3997 | 3998 | ![img](https://tva1.sinaimg.cn/large/008eGmZEly1gobohzda8fj30u00cgaax.jpg) 3999 | 4000 | 4001 | 4002 | 4003 | 4004 | ### 社区直播带货 4005 | 4006 | > 使用**端 / 边 / 云**三级架构，客户端加密传输，边缘节点转发、云侧转码并持久化 4007 | 4008 | #### **产品的背景** 4009 | 4010 | > 上线时间，从调研到正式上线用了 3个月时间，上线后一个月内就要经历双十二挑战。在这么紧的上线时间要求下，需要用到公司提供的所有优势，包括**cdn网络，直播牌照**等 4011 | 4012 | #### 面临的挑战 4013 | 4014 | - 直播数据是**实时**生成的，所有不能够进行**预缓存** 4015 | - 直播随时会发生，举办热点活动，相关服务器资源需要**动态分配** 4016 | - 直播的延迟对于用户体验影响很大，需要控制在**秒级** 4017 | 4018 | - 直播sdk是内嵌在社区应用里的，整体要求不能超过5M 4019 | 4020 | #### 协议的比较 4021 | 4022 | | 协议 | 上线时间 | 网络兼容 | 端对端延迟 | 应用大小 | 问题 | 4023 | | --------------- | -------- | -------- | ---------- | -------- | ---------------------------------------------------- | 4024 | | WebRTC | | ✗ | | | Webrtc 基于 UDP，和社区应用的网络架构不兼容 | 4025 | | HTTP Upload | | | ✗ | | 会导致网络高延迟 | 4026 | | Custom Protocol | ✗ | | | | 工程师需要实现自己的客户端与服务端的库，无法按时上线 | 4027 | | Proprietary | | | | ✗ | 协议就需要几兆的空间，超出额度 | 4028 | | RTMPS | ✔ | ✔ | ✔ | ✔ | TCP实时传输消息协议，更安全更可靠 | 4029 | 4030 | #### 整体流程 4031 | 4032 | **RTMPS**：基于TCP实时传输消息协议，更安全更可靠 4033 | 4034 | **MPEG-DASH**：是一种基于HTTP协议自适应比特率流媒体技术，应对复杂的环境 4035 | 4036 | ![image-20210125145103417](https://i.loli.net/2021/01/25/zjwC7B8fdcpDytA.png) 4037 | 4038 | 1. 直播端使用 **RTMPS** 协议发送直播数据到**边缘节点**（POP） 4039 | 4040 | 2. POP 使用**RTMP**发送数据到数据中心（DC） 4041 | 4042 | 3. DC 将数据编码成**不同的清晰度**并进行持久化存储 4043 | 4044 | **云端转码**主要有**两种分辨率**400x400 和 720x720. 4045 | 4046 | 4. 播放端通过 **MPEG-DASH** / RTMPS 协议接收直播数据 4047 | 4048 | 如果用户网络不好**[MPEG-DASH](https://www.cloudflare.com/zh-cn/learning/video/what-is-mpeg-dash/)**会自动转换成低分辨率 4049 | 4050 | 4051 | 4052 | #### **直播流程** 4053 | 4054 | image-20210125153606264 4055 | 4056 | 1. 直播端使用 **RTMPS** 协议发送直播流数据到 POP 内的就近的代理服务器 4057 | 4058 | 2. 代理服务器**转发**直播流数据到数据中心的网关服务器（**443转80**） 4059 | 4060 | 3. 网关服务器使用**直播 id 的一致性哈希算法**发送直播数据到指定的编码服务器 4061 | 4062 | 4. 编码服务器有几项职责： 4063 | 4064 | - 4.1 **验证直播数据**的格式是否正确。 4065 | 4066 | - 4.2 **关联**直播 id 以及编码服务器第一映射，保证客户端即使连接中断或者服务器扩容时，在**重新连接**的时候依然能够连接到相同的编码服务器 4067 | 4068 | - 4.3 使用直播数据**编码成不同解析度**的输出数据 4069 | 4070 | - 4.4 使用 **DASH** 协议输出数据并**持久化**存储 4071 | 4072 | 4073 | 4074 | #### 播放流程 4075 | 4076 | image-20210125154758184 4077 | 4078 | 1. 播放端使用 HTTP **DASH** 协议向 POP 拉取直播数据 4079 | 2. POP 里面的代理服务器会检查数据是否已经在 POP 的**缓存**内。如果是的话，缓存会返回数据给播放端，否则，代理服务器会向 DC 拉取直播数据 4080 | 3. DC 内的代理服务器会检查数据是否在 DC 的缓存内，如果是的话，缓存会返回数据给 POP，并更新 POP 的缓存，再返回给播放端。不是的话，代理服务器会使用一致性哈希算法向对应的编码服务器请求数据，并更新 DC 的缓存，返回到 POP，再返回到播放端。 4081 | 4082 | 4083 | 4084 | **收获** 4085 | 4086 | 1. 项目的成功不，代码只是内功，考虑适配不同的网络、利用可利用的资源 4087 | 2. 惊群效应在热点服务器以及许多组件中都可能发生 4088 | 3. 开发大型项目需要对**吞吐量和时延**、**安全和性能**做出妥协 4089 | 4. 保证架构的灵活度和可扩展性，为内存、服务器、带宽耗尽做好规划 4090 | 4091 | 4092 | 4093 | ### **直播高可用方案** 4094 | 4095 | **网络可靠性**： 4096 | 4097 | - 根据**网络连接速度**来自动调整视频质量 4098 | - 使用**短时间的数据缓存**来解决直播端不稳定，瞬间断线的问题 4099 | - 根据**网络质量自动降级**为音频直播以及播放 4100 | 4101 | **惊群效应：** 4102 | 4103 | - 当多个播放端向同一个 POP 请求直播数据的时候，如果数据不在缓存中 4104 | - 这时候只有一个请求 A 会到 DC 中请求数据，其他请求会等待结果 4105 | - 但是如果请求 A 超时没有返回数据的话，所有请求会一起向 DC 访问数据 4106 | - 这时候就会加大 DC 的压力，触发惊群效应 4107 | - 解决这个问题的方法就是通过**实际的情况**来调整请求超时的时间。这个时间如果太长的话会带来直播的延迟，太短的话会经常触发惊群效应（**每个时间窗口只允许触发一次**，设置允许最大回源数量） 4108 | 4109 | 4110 | 4111 | ### **性能优化方案** 4112 | 4113 | ![img](https://tva1.sinaimg.cn/large/008eGmZEly1gobogaxxjkj304v0e7t93.jpg) 4114 | 4115 | **数据库优化：** 数据库是最容易成为瓶颈的组件，考虑从 SQL 优化或者数据库本身去提高它的性能。如果瓶颈依然存在，则会考虑分库分表将数据打散，如果这样也没能解决问题，则可能会选择缓存组件进行优化 4116 | 4117 | **集群最优：**存储节点的问题解决后，计算节点也有可能发生问题。一个集群系统如果获得了水平扩容的能力，就会给下层的优化提供非常大的时间空间，由最初的 3 个节点，扩容到最后的 200 多个节点，但由于人力问题，服务又没有什么新的需求，下层的优化就一直被搁置着。 4118 | 4119 | **硬件升级：**水平扩容不总是有效的，原因在于单节点的计算量比较集中，或者 JVM 对内存的使用超出了宿主机的承载范围。在动手进行代码优化之前，我们会对节点的硬件配置进行升级。 4120 | 4121 | **代码优化**：代码优化是提高性能最有效的方式，但需要收集一些数据，这个过程可能是服务治理，也有可能是代码流程优化。比如JavaAgent 技术，会无侵入的收集一些 profile 信息，供我们进行决策。 4122 | 4123 | **并行优化：**并行优化是针对速度慢的接口进行并行调用。所以我们通常使用 ContDownLatch 对需要获取的数据进行并行处理，效果非常不错，比如在 200ms 内返回对 50 个耗时 100ms 的下层接口的调用。 4124 | 4125 | **JVM 优化**： JVM 发生问题时，优化会获得巨大的性能提升。但在 JVM 不发生问题时，它的优化效果有限。但在代码优化、并行优化、JVM 优化的过程中，JVM 的知识却起到了关键性的作用 4126 | 4127 | **操作系统优化：**操作系统优化是解决问题的杀手锏，比如像 HugePage、SWAP、“CPU 亲和性”这种比较底层的优化。但就计算节点来说，对操作系统进行优化并不是很常见。运维在背后会做一些诸如文件句柄的调整、网络参数的修改，这对于我们来说就已经够用了 4128 | 4129 | 4130 | 4131 | ### 流量回放自动化测试 4132 | 4133 | > 系统级的重构，测试回归的工作量至少都是以月为单位，对于人力的消耗巨大。一种应对方案是，先不改造，到系统实在扛不住了再想办法。另一种应对方案是，先暂停需求，全力进行改造。但在实际工作场景中，上述应对策略往往很难实现。 4134 | 4135 | 场景： 4136 | 4137 | 1、读服务均是查询，它是无状态的。 4138 | 4139 | 2、不管是架构升级还是日常需求，读服务对外接口的出入参格式是没有变化的 4140 | 4141 | image-20210504174447049 4142 | 4143 | - **日志收集**，主要作用是收集被测系统的真实用户请求，基于一定规则处理后作为系统用例； 4144 | 4145 | Spring 里的 Interceptor 、Servlet 里的 Filter 过滤器，对所有请求的入参和出参进行记录，并通过 MQ 发送出去。（注意错峰、过滤写、去重等） 4146 | 4147 | - 数据回放是基于收集的用例，对被测系统进行数据回放，发起自动化测试回归； 4148 | 4149 | **离线回放：**只调用新服务，将返回的数据和日志里的出参进行比较，**日志比较大** 4150 | 4151 | **实时回放：**去实时调用线上系统和被测系统，并存储实时返回回放的结果信息，**线上有负担** 4152 | 4153 | **并行回放：**新版本不即时上线，每次调用老版本接口时概率实时回放新版本接口，**耗时间周期** 4154 | 4155 | - **差异对比**，通过差异对比自动发现与预期不一致的用例，进而确定 Bug。 4156 | 4157 | 采用文本对比，可以直观地看到哪个字段数据有差异，从而更快定位到问题。正常情况下，只要存在差异的数据，均可认为是 Bug，是需要进行修复的。 4158 | 4159 | 4160 | 4161 | 4162 | 4163 | 4164 | **方法论** 4165 | 4166 | **Discovery** 4167 | 4168 | ​ 考虑企业战略，分析客户需求，制定产品目标 4169 | 4170 | ​ 由外到内：竞争对手的方案，为什么做，以后怎么发展，如何去优化。 4171 | 4172 | ​ 自上而下：基于公司的战略，考虑自身能力和所处环境。 4173 | 4174 | ​ 自下而上：从资源、历史问题、优先级出发，形成一套可行性实施方法。 4175 | 4176 | **Define** 4177 | 4178 | ​ 基于收集的信息，综合跨业务线的抽象能力和服务，先做什么后做什么，怎么做 4179 | 4180 | ​ 设计新的架构，重点设计解决痛点问题。 4181 | 4182 | ​ 拆分业务领域，重点划分工作临界上下文。 4183 | 4184 | **Design** 4185 | 4186 | ​ 详细的业务设计，功能设计，交付计划，考核计划 4187 | 4188 | ​ 产品愿景，产品形态，相关竞品方案对比，价值、优势、收益 4189 | 4190 | ​ 梳理业务范围，要知道电商领域四大流（信息流、商流、资金流、物流） 4191 | 4192 | ​ MVP最小可用比，让客户和老大看到结果，最后通编写story把故事编圆 4193 | 4194 | **Delivery** 4195 | 4196 | ​ 交付阶段，根据反馈及时调整中台战略，减少损失和增大收益 4197 | 4198 | ​ 合理制定每个阶段的绩效考核目标： 4199 | 4200 | ​ 40%稳定+25%业务创新+20%服务接入+15%用户满意度 4201 | 4202 | 4203 | 4204 | # **七、架构设计** 4205 | 4206 | ## 1、社区系统的架构 4207 | 4208 | image-20210117182546782 4209 | 4210 | **系统拆分** 4211 | 4212 | ​ 通过DDD领域模型，对服务进行拆分，将一个系统拆分为多个子系统，做成SpringCloud的微服务。微服务设计时要尽可能做到少扇出，多扇入，根据服务器的承载，进行客户端负载均衡，通过对核心服务的上游服务进行限流和降级改造。 4213 | 4214 | ​ 一个服务的代码不要太多，1 万行左右，两三万撑死了吧。 4215 | 4216 | ​ 大部分的系统，是要进行**多轮拆分**的，第一次拆分，可能就是将以前的多个模块该拆分开来了，比如说将电商系统拆分成**订单系统、商品系统、采购系统、仓储系统、用户系统**等等吧。 4217 | 4218 | ​ 但是后面可能每个系统又变得越来越复杂了，比如说采购系统里面又分成了**供应商管理系统、采购单管理系统**，订单系统又拆分成了**购物车系统、价格系统、订单管理**系统。 4219 | 4220 | 4221 | 4222 | **CDN、Nginx静态缓存、JVM缓存** 4223 | 4224 | ​ 利用Java的模板thymeleaf可以将页面和数据动态渲染好，然后通过Nginx直接返回。动态数据可以从redis中获取。其中redis里的数据由一个缓存服务来进行消费指定的变更服务。 4225 | 4226 | ​ 商品数据，每条数据是 10kb。100 条数据是 1mb，10 万条数据是 1g。常驻内存的是 200 万条商品数据，占用内存是 20g，仅仅不到总内存的 50%。目前高峰期每秒就是 3500 左右的请求量。 4227 | 4228 | 4229 | 4230 | **缓存** 4231 | 4232 | Redis cluster，10 台机器，5主5从，5 个节点对外提供读写服务，**每个节点的读写高峰 QPS** 可能可以达到每秒 5 万，**5 台机器最多是 25 万读写**请求每秒。 4233 | 4234 | ​ **32G 内存+ 8 核 CPU + 1T** 磁盘，但是分配给 **Redis 进程的是 10g 内存**，一般线上生产环境，Redis 的内存尽量不要超过 10g，超过 10g 可能会有问题。 4235 | 4236 | ​ 因为每个主实例都挂了一个从实例，所以是**高可用**的，任何一个主实例宕机，都会自动故障迁移，Redis 从实例**会自动变成主实例**继续提供读写服务。 4237 | 4238 | 4239 | 4240 | **MQ** 4241 | 4242 | ​ 可以通过消息队列对微服务系统进行[解耦](#1、拆分微服务)，异步调用的更适合微服务的扩展 4243 | 4244 | ​ 同时可以应对秒杀活动中[应对高并发写请求](# 6、应对高并发的写请求)，比如kafka在毫秒延迟基础上可以实现10w级吞吐量 4245 | 4246 | ​ 针对[IOT流量洪峰](#IOT流量洪峰)做了一些特殊的优化，保证消息的及时性 4247 | 4248 | ​ 同时可以使用消息队列保证分布式系统[最终一致性](#7、如何保证数据一致性) 4249 | 4250 | 4251 | 4252 | **分库分表** 4253 | 4254 | ​ 分库分表，可能到了最后数据库层面还是免不了抗高并发的要求，好吧，那么就 将一个数据库拆分为多个库，多个库来扛更高的并发；然后将一个表拆分为多个 表，每个表的数据量保持少一点，提高 sql 跑的性能。**在通讯录、订单和商城商品模块超过千万级别都应及时考虑分表分库** 4255 | 4256 | 4257 | 4258 | **读写分离** 4259 | 4260 | ​ 读写分离，这个就是说大部分时候数据库可能也是读多写少，没必要所有请求都 集中在一个库上吧，可以搞个主从架构，主库写入，从库读取，搞一个读写分离。 读流量太多的时候，还可以加更多的从库。比如**统计监控类的微服务**通过读写分离，只需访问从库就可以完成统计，例如ES 4261 | 4262 | 4263 | 4264 | **ElasticSearch** 4265 | 4266 | ​ Elasticsearch，简称 es。es 是分布式的，可以随便扩容，分布式天然就可以支撑高并发，因为动不动就可以扩容加机器来扛更高的并发。那么一些比较简单的**查询、统计类**的操作，比如**运营平台上**的各地市的汇聚统计，还有一些**全文搜索类**的操作，比如**通讯录和订单**的查询。 4267 | 4268 | 4269 | 4270 | 4271 | 4272 | ## 2、商城系统-亿级商品如何存储 4273 | 4274 | 基于 Hash 取模、一致性 Hash 实现分库分表 4275 | 4276 | 高并发读可以通过[多级缓存](5、应对高并发的读请求)应对 4277 | 4278 | 大促销热key读的问题通过[redis集群+本地缓存+限流+key加随机值](**4、热key问题如何解决？** )分布在多个实例中 4279 | 4280 | 高并发写的问题通过**基于 Hash 取模、一致性 Hash 实现分库分表**均匀落盘 4281 | 4282 | 业务分配不均导致的**热key**读写问题，可以根据业务场景进行range分片，将热点范围下的子key打散 4283 | 4284 | 具体实现：预先设定主键的生成规则，根据规则进行数据的分片路由，但这种方式会侵入商品各条线主数据的业务规则，更好的方式是基于**分片元数据服务器**（即每次访问分片前先询问分片元服务器在路由到实际分片）不过会带来复杂性，比如保证元数据服务器的**一致性**和可用性。 4285 | 4286 | 4287 | 4288 | ## 3、对账系统-分布式事务一致性 4289 | 4290 | > 尽量避免分布式事务，单进程用数据库事务，跨进程用消息队列 4291 | 4292 | 主流实现分布式系统事务一致性的方案： 4293 | 4294 | 1. **最终一致性**：也就是基于 MQ 的可靠消息投递的机制， 4295 | 2. 基于重试加确认的的**最大努力通知方案**。 4296 | 4297 | 理论上也可以使用（2PC两阶段提交、3PC三阶段提交、TCC短事务、SAGA长事务方案），但是这些方案工业上落地代价很大，不适合互联网的业界场景。针对金融支付等需要强一致性的场景可以通过前两种方案实现。（**展开说的话参考分布式事务**） 4298 | 4299 | ![image-20210321212516364](https://tva1.sinaimg.cn/large/008eGmZEly1goruh4oifej30xq0auq7p.jpg) 4300 | 4301 | 本地数据库事务原理：**undo log**（原子性） + **redo log**（持久性） + **数据库锁**（原子性&隔离性） + **MVCC**（隔离性） 4302 | 4303 | 分布式事务原理：**全局事务协调器（原子性）** + 全局锁（隔离性） + **DB本地事务（原子性、持久性）** 4304 | 4305 | 4306 | 4307 | 一、我们公司账单系统和第三方支付系统对账时，就采用“**自研补偿/MQ方案 + 人工介入**”方式 4308 | 4309 | 落地的话：方案最“轻”，性能损失最少。可掌控性好，简单易懂，易维护。 4310 | 考虑到分布式事务问题是小概率事件，留有补救余地就行，性能的损失可是实打实的反应在线上每一个请求上 4311 | 4312 | 4313 | 二、也了解到业界比如阿里成熟**Seata AT**模式，平均性能会降低35%以上 4314 | 4315 | 我觉得不是特殊的场景不推荐 4316 | 4317 | 三、RocketMQ事务消息 4318 | 4319 | 听起来挺好挺简单的方案，但它比较挑业务场景，同步性强的处理链路不适合。 4320 | 【重要】要求下游MQ消费方一定能成功消费消息。否则转人工介入处理。 4321 | 【重要】千万记得实现幂等性。 4322 | 4323 | 4324 | 4325 | ## 4、用户系统-多线程数据割接 4326 | 4327 | 由于项目需要进行数据割接，保证用户多平台使用用户感知的一致，将广东项目的几百万用户及业务数据按照一定的逻辑灌到社区云平台上，由于依赖了第三方统一认证和省侧crm系统，按照之前系统内割接的方法，通过数据库将用户的唯一标识查出来然后使用多线程向省侧crm系统获取结果。 4328 | 4329 | 但是测试的过程中，发现每个线程请求的数据发生了错乱，导致每个请求处理的数据有重复，于是立即停止了脚本，当时怀疑是多线程对资源并发访问导致的，于是把ArrayList 改成了CopyOnWriteArrayList，但是折腾了一晚上，不管怎么修改，线程之间一直有重复数据，叫了一起加班的同事也没看出问题来，和同事估算了一下不使用多线程，大概30-40个小时能跑完，想了下也能接受，本来已经准备放弃了。 4330 | 4331 | 不过回到家，我还是用多线程仔细单步模拟了下，整个处理的过程，发现在起线程的时候，有些子线程并没有把分配给他的全部id的list处理完，导致最终状态没更新，新线程又去执行了一遍，然后我尝试通过修改在线程外深拷贝一个List再作为参数传入到子线程里，（后续clear的时候也是clear老的List）果然，整个测试过程中再也没出现过重复处理的情况。 4332 | 4333 | 事后，我也深究了下原因： 4334 | 4335 | ```java 4336 | if(arrayBuffer.length == 99) { 4337 | val asList = arrayBuffer.toList 4338 | exec.execute ( openIdInsertMethod(asList) ) 4339 | arrayBuffer.clear 4340 | } 4341 | ``` 4342 | 4343 | 在一个线程中开启另外一个新线程，则新开线程称为该线程的子线程，子线程初始优先级与父线程相同。不过主线程先启动占用了cpu资源，因此主线程总是优于子线程。然而，即使设置了优先级，也无法保障线程的执行次序。只不过，优先级高的线程获取CPU资源的概率较大，优先级低的并非没机会执行。 4344 | 4345 | 所以主线程上的clear操作有可能先执行，那么子线程中未处理完的数据就变成一个空的数组，所以就出现了多个线程出现了重复数据的原因，所以我们要保证的是子线程每次执行完后再进行clear即可。而不是一开始定位的保证ArrayList的安全性。所以将赋值(buffer->list)操作放在外面去执行后，多线程数据就正常了。 4346 | 4347 | 4348 | 4349 | ## 5、秒杀系统场景设计 4350 | 4351 | [见秒杀项目方案设计](# 二、秒杀项目) 4352 | 4353 | 4354 | 4355 | ## **6、统计系统-海量计数** 4356 | 4357 | **中小规模的计数服务**（万级） 4358 | 4359 | 最常见的计数方案是采用缓存 + DB 的存储方案。当计数变更时，先变更计数 DB，计数加 1，然后再变更计数缓存，修改计数存储的 Memcached 或 Redis。这种方案比较通用且成熟，但在高并发访问场景，支持不够友好。在互联网社交系统中，有些业务的计数变更特别频繁，比如微博 feed 的阅读数，计数的变更次数和访问次数相当，每秒十万到百万级以上的更新量，如果用 DB 存储，会给 DB 带来巨大的压力，DB 就会成为整个计数服务的瓶颈所在。即便采用聚合延迟更新 DB 的方案，由于总量特别大，同时请求均衡分散在大量不同的业务端，巨大的写压力仍然是 DB 的不可承受之重。 4360 | 4361 | **大型互联网场景**（百万级） 4362 | 4363 | 直接把计数全部存储在 Redis 中，通过 hash 分拆的方式，可以大幅提升计数服务在 Redis 集群的写性能，通过主从复制，在 master 后挂载多个从库，利用读写分离，可以大幅提升计数服务在 Redis 集群的读性能。而且 Redis 有持久化机制，不会丢数据 4364 | 4365 | 一方面 Redis 作为通用型存储来存储计数，内存存储效率低。以存储一个 key 为 long 型 id、value 为 4 字节的计数为例，Redis 至少需要 65 个字节左右，不同版本略有差异。但这个计数理论只需要占用 12 个字节即可。内存有效负荷只有 12/65=18.5%。如果再考虑一个 long 型 id 需要存 4 个不同类型的 4 字节计数，内存有效负荷只有 (8+16)/(65*4)= 9.2%。 4366 | 4367 | 4368 | 另一方面，Redis 所有数据均存在内存，单存储历史千亿级记录，单份数据拷贝需要 10T 以上，要考虑核心业务上 1 主 3 从，需要 40T 以上的内存，再考虑多 IDC 部署，轻松占用上百 T 内存。就按单机 100G 内存来算，计数服务就要占用上千台大内存服务器。存储成本太高。 4369 | 4370 | **微博、微信、抖音**（亿级） 4371 | 4372 | 定制数据结构，共享key 紧凑存储，提升计数有效负荷率 4373 | 4374 | 超过阈值后数据保存到SSD硬盘，内存里存索引 4375 | 4376 | 冷key从SSD硬盘中读取后，放入到LRU队列中 4377 | 4378 | 自定义主从复制的方式，海量冷数据异步多线程并发复制 4379 | 4380 | 4381 | 4382 | ## 7、系统设计 - 微软 4383 | 4384 | ### **1、需求收集** 4385 | 4386 | 确认**使用的对象**（ToC：高并发，ToB：高可用） 4387 | 4388 | **系统的服务场景**（**即时通信**：低延迟，**游戏**：高性能，**购物**：秒杀-一致性） 4389 | 4390 | **用户量级**（**万级**：双机、**百万**：集群、**亿级**：弹性分布式、容器化编排架构） 4391 | 4392 | **百万读**：3主6从，**每个节点的读写高峰 QPS** 可能可以达到每秒 5 万，可以实现15万，30万读性能 4393 | 4394 | **亿级读**，通过CDN、静态缓存、JVM缓存等多级缓存来提高读并发 4395 | 4396 | **百万写**，通过消息队列削峰填谷，通过hash分拆，水平扩展分布式缓存 4397 | 4398 | **亿级写**，redis可以定制数据结构、SSD+内存LRU、冷数据异步多线程复制 4399 | 4400 | 持久化，（Mysql）承受量约为 1K的QPS，读写分离提升**读并发**，分库分表提升**写并发** 4401 | 4402 | 4403 | 4404 | ### **2、顶层设计** 4405 | 4406 | 核心功能包括什么： 4407 | 4408 | 写功能：发送微博 4409 | 4410 | 读功能：热点资讯 4411 | 4412 | 交互：点赞、关注 4413 | 4414 | 4415 | 4416 | ### **3、系统核心指标** 4417 | 4418 | - 系统**性能**和**延迟** 4419 | - 边缘计算 | 动静分离 | 缓存 | 多线程 | 4420 | - **可扩展性**和**吞吐量** 4421 | - 负载均衡 | 水平扩展 | 垂直扩展 | 异步 | 批处理 | 读写分离 4422 | - **可用性**和**一致性** 4423 | - 主从复制 | 哨兵模式 | 集群 | 分布式事务 4424 | 4425 | 4426 | 4427 | ### 4、数据存储 4428 | 4429 | 键值存储 : Redis ( 热点资讯 ) 4430 | 4431 | 文档存储 : MongoDB ( 微博文档分类) 4432 | 4433 | 分词倒排：Elasticsearch（搜索） 4434 | 4435 | 列型存储：Hbase、BigTable（大数据） 4436 | 4437 | 图形存储：Neo4j （社交及推荐） 4438 | 4439 | 多媒体：FastDfs（图文视频微博） 4440 | 4441 | 4442 | 4443 | 4444 | 4445 | ## 7、如何设计一个微博 4446 | 4447 | **实现哪些功能：** 4448 | 4449 | 筛选出核心功能（Post a Tweet，Timeline，News Feed，Follow/Unfollow a user，Register/Login） 4450 | 4451 | **承担多大QPS：** 4452 | 4453 | QPS = 100，那么用我的笔记本作Web服务器就好了 4454 | 4455 | QPS = 1K，一台好点的Web 服务器也能应付，需要考虑单点故障； 4456 | 4457 | QPS = 1m，则需要建设一个1000台Web服务器的集群，考虑动态扩容、负载分担、故障转移 4458 | 4459 | 一台 SQL Database （Mysql）承受量约为 1K的QPS； 4460 | 4461 | 一台 NoSQL Database (Redis) 约承受量是 20k 的 QPS； 4462 | 4463 | 一台 NoSQL Database (Memcache) 约承受量是 200k 的 QPS； 4464 | 4465 | **微服务战略拆分** 4466 | 4467 | img 4468 | 4469 | **针对不同服务选择不同存储** 4470 | 4471 | ![img](https://pic1.zhimg.com/80/v2-13cab4d5f56e3ecb682c351c0eb4a24b_1440w.jpg?source=1940ef5c) 4472 | 4473 | **设计数据表的结构** 4474 | 4475 | ![img](https://tva1.sinaimg.cn/large/008eGmZEly1goruu4homyj31400ht405.jpg) 4476 | 4477 | 基本差不多就形成了一个解决方案，但是并不是完美的，仍然需要小步快跑的不断的针对**消息队列、缓存、分布式事务、分表分库、大数据、监控、可伸缩**方面进行优化 4478 | 4479 | 4480 | 4481 | 4482 | 4483 | # 八、领域模型落地 4484 | 4485 | ### 1、拆分微服务 4486 | 4487 | > ​ 微服务内高内聚，微服务间低耦合 4488 | 4489 | **微服务内高内聚**即单一职责原则 4490 | 4491 | ​ 每个微服务中的代码变化都是同一类原因。因这类原因而需要变更的代码都在这个微服务中，与其他微服务无关，那么就可以将代码修改的范围缩小到这个微服务内。把这个微服务修改好了，独立修改、独立发布，该需求就实现了。这样，微服务的优势才能发挥出来。 4492 | 4493 | **微服务间低耦合**开放封闭原则 4494 | 4495 | ​ 就是说在微服务实现自身业务的过程中，如果需要执行的某些过程不是自己的职责，就应当将这些过程交给其他微服务去实现，你只需要对它的接口进行调用。这样，微服务之间的调用就实现了解耦。 4496 | 4497 | [^譬如]: “访客申请”微服务在审批流程中需要查询用户信息，但“查询用户信息”不是它的职责，而是“核心通讯录”微服务的职责。这样，“访客申请”微服务就不需要再去执行对用户信息的查询，而是直接调用“核心通讯录”微服务的接口。那么，怎样调用呢？直接调用可能会形成耦合。可以通过注册中心，“访客申请”微服务调用的只是在注册中心中名称叫“核心通讯录”的微服务。而在分省软件设计时，“核心通讯录”可以有多个实现，哪个注册到注册中心中，就调用哪个。 4498 | 4499 | ​ **领域建模**就是将一个系统划分成了多个子域，每个子域都是一个独立的业务场景，每个子域的边界就是“**限界上下文**”。该业务场景会涉及许多领域对象，但**分析建模**始终需要围绕着业务场景的上下文进行。 4500 | 4501 | ​ **领域事件通知机制**最有效的方式就是通过消息队列，实现领域事件在微服务间的通知。 4502 | 4503 | > “核心通讯录”微服务只负责发送变更消息到消息队列，不管谁会接收并处理这些消息； 4504 | > 4505 | > “门禁管理”微服务只负责接收照片变更消息，不管谁发送的这个消息。 4506 | 4507 | 4508 | 4509 | ### 2、关联微服务 4510 | 4511 | 1. 按照**限界上下文**进行微服务的拆分，将领域模型**划分到多个问题子域** 4512 | 4513 | 2. 基于**充血模型**与**贫血模型**设计各个微服务的业务领域层（Service、Entity、Value） 4514 | 4515 | 3. 通过**领域事件通知机制**和**微服务调用**的推拉结合，将各个子域进行解耦关联 4516 | 4517 | - **核心**： 4518 | - 通讯录 | 短信 | 推送通知 | 支付 | 文件服务 4519 | 4520 | - **智慧通行** 4521 | 4522 | > 解决物业多品牌、多系统应用造成的**信息孤岛**，**数据混乱**的问题 4523 | 4524 | - 人脸门禁 | 可视对讲 | 电梯梯控 | 停车系统 | 访客预约 4525 | 4526 | - **安全社区** 4527 | 4528 | > 通过**图像视频识别**、**传感数据采集**，实现**报警联动**和**风险预警** 4529 | 4530 | - 视频监控 | 周界报警 | 高空抛物 | 跨域追踪 4531 | 4532 | - **全屋智能** 4533 | 4534 | > 围绕业主需求，逐步引入社区医疗、社区养老、**社区团购**、**社区家政**等服务 4535 | 4536 | - 超级面板 | 无线门锁 | 烟感雾感 4537 | 4538 | - **增值服务** 4539 | 4540 | > 实现跨品牌的产品体验，支持基于**matrix引擎**的智能生活场景裂变能力 4541 | 4542 | - 智能充电 | 云广播 | 出入提醒 | 定向投放 4543 | 4544 | 4545 | 4546 | ### **3、微服务的落地** 4547 | 4548 | > ​ 通过合理的微服务设计，尽量让每次的需求变更都交给某个小团队独立完成，让需求变更落到某个微服务上进行变更。唯有这样，每次变更只需独立地修改这个微服务，独立打包、独立升级，新需求独立实现，才能发挥微服务的优势。 4549 | 4550 | - **数据隔离：**数据库中用户信息表的读写只有**通讯录**微服务。当其他微服务需要读写用户信息时，就不能直接读取用户信息表，而是通过 API 接口去调用**通讯录**微服务。 4551 | - **接口复用：**因此，当多个团队向你提需求时，必须要对这些接口进行规划，通过复用**尽可能少的接口满足他们的需求；**当有新的接口提出时，要尽量通过现有接口解决问题。 4552 | - **向前兼容：**当调用方需要接口变更时怎么办？变更现有接口应当尽可能向前兼容，即接口的名称与参数都不变，只是在内部增加新的功能。**宁愿增加一个新的接口也最好不要去变更原有的接口。** 4553 | - **本地调用：**在**访客申请**微服务的本地，增加一个**查询用户Service**的 feign 接口。这样，**访客申请Service**就像本地调用一样调用**查询用户Service**，再通过 feign 接口实现远程调用。这种**防腐层**的设计，可以隔离当前微服务以外的其他微服务拆分变更导致的接口的失效的影响。 4554 | - **数据库去中心化：** 4555 | 4556 | - 微服务中**通讯录服务**与**健康码服务**分别对应的**用户库与权限库**，它们的共同特点是数据量小但频繁读取，可以选用小型的 MySQL 数据库并在前面架设 Redis 来提高查询性能； 4557 | - 微服务中**访客通行**与**生活缴费**分别对应的**通行记录库、订单库**，其特点是数据量大并且高并发写，选用一个数据库显然扛不住这样的压力，因此可以选用了 TiDB 这样的 NewSQL 数据库进行分布式存储，将数据压力分散到多个数据节点中，从而解决 I/O 瓶颈； 4558 | - 微服务中**数据分析**与**通讯录查询**这样的查询分析业务，则选用 **NoSQL 数据库**或**大数据平台**，通过读写分离将生产库上的数据同步过来进行分布式存储，然后宽表一系列的预处理，应对海量历史数据的决策分析与秒级查询。（ NoSQL 为空的字段是不占用空间的，因此字段再多都不影响查询性能） 4559 | 4560 | 4561 | 4562 | ### 4、领域模型的意义 4563 | 4564 | ​ **贫血模型、充血模型、策略模式、装饰者模式**只是DDD实现的方式，而DDD的真谛是**领域建模**。 4565 | 4566 | ​ 做事不能仅凭一腔热血，一定要符合自然规律。其实软件的设计开发过程也是这样。对业务理解不深刻全局架构设计往往是过度设计，这时候**应该抓主要流程**，开始领域建模。 4567 | 4568 | - 接着，每次添加新功能的时候，一方面要满足当前的需求，另一方面业务相关的**领域建模设计**刚刚满足需求，从而使设计最简化、代码最少。 4569 | - 这样的设计过程叫**小步快跑**。采用小步快跑的设计方法，一开始不用思考那么多问题，从简单问题开始逐步深入。**领域模型**就像小树一样一点儿一点儿成长，最后完成所有的功能。 4570 | 4571 | > 保持软件设计不退化的关键在于每次需求变更的设计，只有保证每次需求变更时做出正确的设计，才能保证软件以一种良性循环的方式不断维护下去。 4572 | 4573 | ​ 有没有一种方法，让我们在第十次变更、第二十次变更、第三十次变更时，依然能够找到正确的设计呢？有，那就是**领域驱动设计** 4574 | 4575 | ​ 那么在每次需求变更时，将变更还原到真实世界中，看看真实世界是什么样子的，根据真实世界进行变更。 4576 | 4577 | 4578 | 4579 | ### 5、战略建模 4580 | 4581 | ​ image-20210504174616848 4582 | 4583 | 4584 | 4585 | ### **6、相关名词** 4586 | 4587 | **领域和子域（Domain/Subdomain）** 4588 | 4589 | ​ 在**上下文地图**构建的领域中，对应模块，使用**限界上下文**划分领域，对应微服务 4590 | 4591 | **限界上下文（Bounded Context）** 4592 | 4593 | ​ 在一个领域/子域中，有概念上的领域边界，任何**领域对象**在该边界内部的有不依赖外部的确切含义。 4594 | 4595 | **领域对象** 4596 | 4597 | ​ 服务、实体与值对象是领域驱动设计的领域对象，可以通过**贫血模型**和**充血模型**转换为程序设计 4598 | 4599 | **实体和值对象** 4600 | 4601 | ​ 通过一个**唯一标识字段来区分**真实世界中的每一个个体的领域对象，称为实体。真实世界中那些**一成不变的**、本质性的事物的领域对象，称为值对象。 **可变性**是实体的特点，而**不变性**则是值对象的本质。 4602 | 4603 | **贫血模型与充血模型** 4604 | 4605 | ​ POJO对象中只保存get/set方法，没有任何业务逻辑，这样的设计被称为**贫血模型** 4606 | 4607 | ​ **充血模型**是封装和继承思想的体现，门禁设备实体中，包含特征值下发、广告下发、通行记录回调等方法，不同厂商的实体针对多态进行**聚合**，并通过**工厂或仓库**对外提供服务。在充血模型中， Service 只干一件非常简单的事，就是直接去调用对象中的**工厂方法**生成不同产品，其他的什么都不干。 4608 | 4609 | **聚合** 4610 | 4611 | ​ 聚合体现的是一种**整体与部分**的关系。正是因为有这样的关系，在操作整体的时候，整体就封装了对部分的操作。如何正确理解是否存在聚合的关系：就是当**整体不存在**时，部分就变得**没有了意义**。部分是整体的一个部分，与**整体有相同的生命周期**。 4612 | 4613 | **工厂** 4614 | 4615 | **通过装配，创建领域对象，是领域对象生命周期的起点。**譬如，系统要通过 ID 装载一个访客申请： 4616 | 4617 | 1. 表单工厂分别调用表单信息DAO、表单明细 DAO 和用户DAO 去进行查询； 4618 | 4619 | 2. 将得到的表单明细对象、用户对象进行装配，分别 set 到**表单信息对象**的**表单明细**与**用户属性**中； 4620 | 3. 最后，表单工厂将装配好的表单对象返回给表单仓库。 4621 | 4622 | **仓库** 4623 | 4624 | ​ 如果服务器是一个非常强大的服务器，那么我们不需要任何数据库。系统创建的所有领域对象都放在仓库中，当需要这些对象时，通过 ID 到仓库中去获取。 4625 | 4626 | - 当客户程序通过 ID 去获取某个领域对象时，仓库会通过这个 ID 先到**缓存中进行查找**： 4627 | 4628 | - 查找到了，则**直接返回**，不需要查询数据库； 4629 | 4630 | - 没有找到，则通知工厂，工厂调用 DAO 去数据库中查询，然后**装配成领域对象返回给仓库**。 4631 | 4632 | - 仓库在收到这个领域对象以后，在返回给客户程序的同时，将该**对象放到缓存中** 4633 | 4634 | 4635 | 4636 | 4637 | 4638 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # javaDesign 2 | 3 | Hello ，大家好，我是一个JAVA后端研发工程师，之前在国企IT工作，去年十月规划了下，决定来互联网看看机会。从十月开始到今年三月，利用下班时间开启了812（每晚8点到12点）学习模式。 4 | 5 | 今年三月开始找新工作，凭借着整理的这份资料，加上[leetcode](https://leetcode-cn.com/u/idasmilence/)刷的将近600道题，一个月的时间内，拿到了蚂蚁金服、快手、拼多多、淘宝、微软等大厂offer 6 | 7 | 凭我的经验，大纲基本囊括了90%的知识点，面试中总有一些疑难偏怪知识点，遇到这类我建议大方承认，但是记住一次面试最多承认一个知识点不是自己专业领域范围的知识，不懂的多的时候要靠临场发挥或者转移话题了。目前已入职阿里淘系交易，欢迎大家找我内推（idahenji@gmail.com） 8 | --------------------------------------------------------------------------------