m0_56709616的博客

【代码】11 Redis大厂真实需求落地案例实战。

如果redis中有数据：需要和数据库中的值相同如果redis中无数据：数据库中的值要是最新值请求A进行写操作，删除缓存后，工作正在进行中…A还么有彻底更新完请求B开工，查询redis发现缓存不存在请求B继续，去数据库查询得到了myslq中的旧值请求B将旧值写入redis缓存请求A将新值写入mysql数据库上述情况就会导致不一致的情形出现。如果数据库更新失败，导致B线程请求再次访问缓存时，发现redis里面没数据，缓存缺失，再去读取mysql时，从数据库中读取到旧值。

MySQL的主从复制将经过如下步骤：开启 MySQL的binlog写入功能授权canal连接MySQL账号mysql默认的用户在mysql库的user表里默认没有canal账户，此处新建+授权canal服务端下载解压后整体放入/mycanal路径下配置修改/mycanal/canal.deployer-1.1.5/conf/example路径下instance.properties换成自己的在mysql新建的canal账户建module改pom写YML主启动业务

int保存long 型(长整型)的64位(8个字节)有符号整数只有整数才会使用 int，如果是浮点数， Redis 内部其实先将浮点数转化为字符串值，然后再保存。embstr代表 embstr 格式的 SDS(Simple Dynamic String 简单动态字符串),保存长度小于44字节的字符串EMBSTR 顾名思义即：embedded string，表示嵌入式的Stringraw保存长度大于44字节的字符串。

定期删除策略的难点是确定删除操作执行的时长和频率：如果删除操作执行得太频繁，或者执行的时间太长，定期删除策略就会退化成立即删除策略，以至于将CPU时间过多地消耗在删除过期键上面。如果删除操作执行得太少，或者执行的时间太短，定期删除策略又会和惰性删除束略一样，出现浪费内存的情况。因此，如果采用定期删除策略的话，服务器必须根据情况，因此，如果只采用定期删除策略，会导致很多key到时间没有删除。周期性轮询redis库中的时效性数据，采用随机抽取的策略，利用过期数据占比的方式控制删除频度。

**} }synchronized单机版OK，上分布式nginx分布式微服务，单机锁不行/(ㄒoㄒ)/~~取消单机锁，上redis分布式锁setnx只加了锁，没有释放锁，出异常的话，可能无法释放锁，必须要在代码层面finally释放锁宕机了，部署了微服务代码层面根本没有走到finally这块，没办法保证解锁，这个key没有被删除，需要有lockKey的过期时间设定为redis的分布式锁key，增加过期时间。

是什么危害建Module：bloomfilter_demo改POM写YML主启动业务类布隆过滤器说明方案3：Redis布隆过滤器解决缓存穿透Guava缺点说明：Guava 提供的布隆过滤器的实现还是很不错的 （想要详细了解的可以看一下它的源码实现），但是它有一个重大的缺陷就是只能单机使用 ，而现在互联网一般都是分布式的场景。案例：白名单过滤器白名单架构说明误判问题，但是概率小可以接受，不能从布隆过滤器删除全部合法的key都需要放入过滤器+redis里面，不然数据就

使用时最好不要让实际元素数量远大于初始化数量当实际元素数量超过初始化数量时，应该对布隆过滤器进行重建，重新分配一个 size 更大的过滤器，再将所有的历史元素批量 add 进行。

JD购物车早期 设计目前不再采用，当前小中厂可用。

Redis自身出道就是优秀，基于内存操作、数据结构简单、多路复用和非阻塞 I/O、避免了不必要的线程上下文切换等特性，在单线程的环境下依然很快；但对于大数据的 key 删除还是卡顿厉害，因此在 Redis 4.0 引入了多线程unlink key/flushall async 等命令，主要用于 Redis 数据的异步删除；

Java架构师系列导航目录

Java架构师系列导航目录

加速优化监控统计安全性。

根据实际业务管理的需要，对硬件、软件以及所要用到的技术进行规格的选择狭义上的技术选型：团队决定选用哪种技术去解决问题，比如选用某个技术语言、某个技术框架去开发项目广义上的技术选型：泛指项目实施过程中的各种技术决策制定了技术方案A & B，选择其中一套每个技术决策都是技术选型。

架构设计模式01 架构设计模式导航与分层架构初始认知02 分层架构模式（Layered Arch）03 事件驱动架构模式（Event driven Arch）04 微内核架构（可扩展）模式05 生产者消费者模式架构设计评估01 如何评估服务性能02 系统测试与调优指标03 如何评估系统容量04 如何评估架构设计的前瞻能力分布式架构理论01 分布式系统理论02 底层数据设计策略 - 分库分表，热点热数据隔离03 底层数据设计策略 - 高可用数据04 中间件和平台运

Spring的MySQLMaxValueIncrementer。优点：取得号段之后，不再强依赖数据库。缺点：趋势递增的，而非单调递增。

结论2：执行成功，latin1字符集的varchar字段可以存储加密后的数据，varbinary、binary、blob可以存储加密后的数据（基于二进制存储）结论1：添加数据操作执行失败，因为utf-8字符集的varchar字段无法存储加密后的数据。对于无法解密的数据，aes_decrypt会直接返回null。方案1：用hex()转16进制存储。方案2：转base64存储。

数据库架构设计的基本思路需求分析阶段（最困难、最耗时）整个设计过程的基础需求分析做得是否充分以及准确，决定了数据库设计的速度与质量极端场景下，需求分析做得不好，可能会导致整个数据库设计返工、重做需求分析目标了解系统的工作情况明确用户的各种需求在此基础上确定新系统的功能明确信息要求、数据要求、处理要求、安全性要求调查用户需求的步骤调查用户需求的方法开调查会跟班作业请专人介绍调查表查阅记录每种方式都需要用户的参与和配合分析用户需求结构化

弹性思考无状态进程同步并发解耦思考配置和密码分离后台服务端口绑定中台思考日志流多节点汇聚多维度分析大流量处理、归档、备份标准输出 + 不代理、不保存、不处理管理作业认证授权监控遥测健康性能追踪API经济中台思维Mobile First服务合同SLA云原生最高境界：IaaS -> PaaS -> SaaS

云环境的分类混合云为什么选择混合云混合云网络互联入口层分流CDN内容分发网络CDN工作原理Captcha图灵测试SLB软件负载均衡器SDN：软件定义网络网络层次：通用网络（2-4层）和HTTP（5-7层）多种实现：通用网络（LVS/F5-LTM/HAProxy）、HTTP（Nginx/Tengine/F5-LTM/HAProxy）Nginx反向代理安全防御系统层安全入侵检测病毒查杀漏洞智能修复网页防篡改基线一键检查潜在安全风险网络层安全DD

系统安全系统安全威胁病毒蠕虫特洛伊木马Rootkit后门僵尸网络零日攻击Webshell操作系统防御杀毒软件：兵来将挡，水来土掩升级补丁：防止零日攻击限制：用户、网络、端口、程序、安全基准、不可变基础架构杀毒软件检测机制特征型：模式匹配、指纹检测启发型：逻辑评估、人工智能、防止零日攻击完整性检查：通过CRC校验确认文件的完整性行为阻止：执行代码，监控它和操作系统的交互免疫系统：把自己变得像是已经被感染，博取同情沙箱运行：限制病毒和可疑代码的影响数据库安全

授权码模式：完整、严密，第三方认证和授权的最主流实现。密码模式：王者荣耀瘾君子、用户名密码都给你也无妨。简化模式：令牌用户可见，移动端的常用实现手段。客户端模式：王者荣耀开发团队、用户就是客户端。

网络设备安全——防火墙状态检测应用级代理防火墙实战默认禁止：Ingress和Egress高安全域优先：允许高安全域发起请求规则具体：源地址（标签）、源端口，目标地址（标签）、目标端口、通信协议（TCP、UDP、ICMP）、方向（Ingress、Egress）网络设备安全——CDN内容分发网络网络攻击Dos拒绝服务攻击畸形数据包：如超长ICMP、泪滴攻击泛洪攻击：SYN泛洪、DHCP泛洪、ARP泛洪、UDP泛洪分布式DDoS：僵尸网络、肉鸡攻击DNS缓存投毒和劫持

设计原则透明对开发者透明在做实现时，不依赖于单元划分和部署对组件透明在组件运行时，不感知其承载单元对数据透明数据库并不知道为哪个单元提供服务业务可分片系统业务复杂度足够高系统可以按照某一维度进行切分系统数据必须可以被区分业务自包含同一业务功能必须在单元内完成同一业务操作所需数据也在该功能单元内尽量避免跨单元依赖单元化设计三要素系统切分业务切分DDD切分领域服务、数据和业务流程切分出的服务和数据属于同一单元出现交集（重叠）时，以单元间访问量做决策指标

组件时单元化架构里最小的原子单位一个组件就是代表一组业务功能或服务组件自定义范围和形态，在其定义域内独立运行组件依赖于其他组件，也可以被其他组件依赖。

扩展性（Scalability）高伸缩性添加资源就可以应对处理能力需求的增长用户、流量、数据增长，性能指标不下降度量增加系统处理能力的指标系统性能延迟：系统处理单词请求所需的时间吞吐量：单位时间内系统处理次数伸缩性&性能&成本等综合结果伸缩性差单用户性能正常用户增长后性能指标下降性能提升的成本高横向扩展（Horizontal Scale）Scale out增加更多机器，提高系统整体性能和处理能力分布式架构理论上可以无限扩展经济成本

业务埋点的技术选型方向淘系用户画像的业务目标业务埋点三板斧后台业务埋点业务埋点：在业务流程中添加埋点代码注解埋点：利用SPring的AOP机制可视化埋点无痕埋点项目中怎么选链路监控中的离群点分析微服务间的链路梳理

为什么需要统一配置管理中心架构选型层面如何考量配置中心的高可用拒绝单点主从、集群服务治理配置服务也是一种服务本地文件备份和全局ID发号器相同思想：比如生成订单编号，先从服务器申请一批，然后缓存在本地，高并发场景下一个一个往外发放，减少和数据库的交互次数，等到用完了再申请一批。要想做到高可用，就需要假设任何一环都不可靠，提高总体的可用性。

微服务架构设计核心微服务服务治理服务生命周期主链路规划网络层搭建配置管理服务监控和调用链梳理业务埋点无痕埋点用户画像采集离散点分析调用链梳理微服务的服务治理服务注册服务发现服务续约、心跳注册中心剔除服务服务自主下线淘系下单场景的主链路案例分享用户流量漏斗模型

既然使用缓存，那就肯定会存在缓存数据和DB数据不一致的问题，只是不一致时间长短的问题。DNS服务器将访问的域名转发到对应的网关，网关层做反向代理。经过一段时间使用后，发现一些潜在的Bug。适合用消息组件解耦的场景。

订单交易核心链路。

冷备 + 热备（数据实时镜像、同步）Canal是这类问题的终结者。

分库分表数据的迁移和扩容（备库转主库，2N扩容）商品是典型的读多写少的场景。

每隔指定时间发布leader证，持有该证书的节点是leader。时间依赖于当前机器的时钟，因此会有时钟误差问题，需要保证集群内机器的时钟是同步的，一般设置在10秒钟的量级。保证集群的可用性，最少有大于一般的机器处于可用状态。

推到重来的商品中心微服务化推行的时间过晚单体应用也要模块化（pom级别抽离出来，每个都是一个module），方便后续业务量上来之后做微服务商品、库存、订单、营销、购物车、搜索、后台系统业务预估不足今早考虑分库分表，即便是假分库。初期项目刚开始的时候，操作成本低，所以有可能会有爆发式增长的业务，今早考虑终止状态商品发布案例，会给商品发布不同的情况设置不同的状态码。然后会有补偿的Job的扫描，放到MQ队列里面重试。这种情况下如果前端传输过来一个不存在的状态码，就会一直重试，类似于

阿里系业务容量规划Tair集群部署与水位调配阿里系容量精调之单机压测场景传统模拟请求流量复制流量转发网关权重线上测试注意点阿里系混合部署技术资源分时复用：提高资源利用率sigama框架做在线资源池调度，伏羲做离线资源池调度；两者之上有顶层混部调度生产级限流维度和前端柔性方案网关流控限流全局维度用户维度IP维度Sentinel：调用方限流、热点限流准入黑名单白名单DDos高防整形预热、冷启动匀速通过排队机制：把当前先到的请

【代码】07 - 02 系统测试与调优指标。

软件架构的评估理论ATAM评估方法表述部分（开局）调查分析（对线）场景讨论报告生成CBAM成本效益评估方法优先级评估烧脑计算服务性能指标和调优思路案例分析：新零售业务商品搜索的隐匿bug

QueuePub/Sub

核心系统提供的接口及版本上下文（context），环境参数回调（call back）、钩子（hook）、事件（event）集成规范同步/异步本地/远程数据格式。