摘要：
【IT老齐075】高可用架构避免单点经典方案Keepalived＋VIP 规避单点是高可用架构设置最基本的考量 概念 Keepalived Keepalived是Linux轻量级别的高可用解决方案 Keepalived主要是通过虚拟路由几余 (VRRP) 来实现高可用功能，Keepalived部署和 阅读全文
摘要：
【IT老齐074】海量数据大页码MySQL查询 场景 分页最后数据查询慢，添加索引，索引失效 SELECT * FROM blog_browse_history ORDER BY create_time LIMIT 500000, 10; 查询优化 利用索引覆盖特性查找第50000页的起始时间，基于 阅读全文
摘要：
【IT老齐072】全文检索执行原理 全文检索引擎就是对非结构化文本进行解析、搜索的技术 非结构化文本的处理关键在于分词与倒排索引 分词 分词是指将一段文本中有用的词汇提取出来 常见的中文分词算法 Ngram穷举 n=2 语法分析+字典: 按中文动名词分析推测外加分词字典维护 爬虫+大数据+AI分析: 阅读全文
摘要：
【IT老齐072】全文检索执行原理 https://lamport.azurewebsites.net/pubs/lamport-paxos.pdf Paxos算法是Lamport宗师提出的一种基于消息传递的分布式一致性算法，使其获得2013年图灵奖。 在Zookeeper中，通过Paxos算法选举 阅读全文
摘要：
【IT老齐070】@Transactional注意 场景 原因 经过对比排查，在支付数据原始数据报文中，由于X行上报数据中的存在备选日期 (字符串类型)字段，上报后包含隐藏字符，导致生成任务时无法按预期解析，抛出ParseException导致批处理流程中断 @Transactional注解的特性是 阅读全文
摘要：
【IT老齐069】日志收集架构 标准ELK 优点：部署最简单组件使用最少 缺点：由于 Logstash 同时兼顾了收集和解析的工作所以比较耗 CPU 和 内存资源，只适合服务器资源丰富的场景，否则容易容易造成性能下降甚至影响应用本身的正常工作 TCP推送 优点：对比架构一各个应用服务器不需要额外部署 阅读全文
摘要：
【IT老齐068】高并发电商缓存访问倾斜 热点数据特征 短时访问超高 数据总量相对较少 接口方案 热门数据分片 区分热点数据 美团：默认大促时参与活动的商品 京东：用户行为分析与大数据评估 缓存前置 + 闪电缓存 阅读全文
摘要：
【IT老齐065】分布式流控神器Alibaba Sentinel 在Spring Cloud Alibaba生态中有一个重要的流控组件Sentinel，Sentinel 以流量为切入点，从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。 http://sentinelguard.io/z 阅读全文
摘要：
【IT老齐064】微服务架构作用 单体架构 问题 微服务 所谓微服务架构风格是一种将单个应用程序开发为一组小型服务的方法，每个小服务运行在自己的进程中，并以轻量级的机制(通常是HTTP RESTful AP)的方式进行通信。这些服务围绕着业务能力所建立的，并且可以由完全自动化的部署机构独立部署，这些 阅读全文
摘要：
【IT老齐063】秒杀场景下解决商品库存超卖问题 超卖问题 核心问题 秒杀商品库存总量固定 先到先得，瞬间并发极大，但写库量有限 解决方案 利用预减库存方式杜绝超卖 利用Nginx+Lua在网关层面将无效请求阻挡 利用MQ消息队列的限流特性保证MySQL不会被瞬间击垮 APP需要额外设计轮询机制查询 阅读全文
摘要：
【IT老齐062】缓存一致性 Cache Aside Pattern 禁止先删缓存，后更新数据库 推荐先更新数据库，在删除缓存 极端情况 延迟双删 阅读全文
摘要：
【IT老齐061】BASE最终一致性 CAP理论下，常用的AP方案的补全手段 Basically Available（基本可用） Soft state（软状态） Eventually consistent（最终一致性） 基本可用就是快速实现用户的基本价值与诉求，“创建订单”后立即返回就是基本可用的体 阅读全文
摘要：
【IT老齐058】Zookeeper解决分布式系统商品库存超卖问题 场景 解决方案 传统的synchronized是无效的，它只针对一个JVM进程内多个线程起到同步作用，对跨进程无效。 利用数据库select ... for update 语句对库存进行锁定，依赖数据库自身特性，遇到跨库（分库分表） 阅读全文
摘要：
【IT老齐057】Raft选举算法 用途 Raft 算法是分布式系统开发首选的共识算法 主要在分布式集群架构下进行领导者 (主节点)的确认。 比如现在流行的组件 Etcd、Consul、Nacos、RocketMQ、Redis Sentinel 底层都是采用Raft算法来确认集群中的主节点，再通过主 阅读全文
摘要：
【IT老齐056】日千万级订单系统的高可用、高性能架构 原始场景 避免丢单 关键逻辑不要使用读写分离的查询方式，避免从库同步延迟造成订单查询异常 关键逻辑也不要使用缓存来进行订单的查询 订单补偿不要粗暴地使用消息队列的方式，避免中间件引发的订单丢失 接收消息处理失败时一定要让消息重试，避免丢失 日万 阅读全文
摘要：
【IT老齐055】Mysql Ngram全文检索技术 场景 select * from article where title like Java% 可能用到索引,看索引选择性 select * from article where titledlike %Java 一定不会用到索引 select 阅读全文
摘要：
【IT老齐054】MongoDB介绍 场景 特点 多形性: 同一个集合中可以包含不同字段(类型)的文档对象 动态性：线上修改数据模式，修改是应用与数据库均无须下线 数据治理：支持使用JSON Schema来规范数据模式。在保证模式灵活动态的前提下，提供数据治理能力 速度优势 数据库引擎只需要在一个存 阅读全文
摘要：
【IT老齐053】动静分离架构抗住超高并发访问 架构三大分离设计 读写分离 动静分离 前后台分离 概念 有效区分页面中的动静数据是优化的关键前提 静态数据是无个性化数据 静态文件: HTML/CSS/JS/图片 低频变动数据: 字典数据/地区数据 /组织架构历史数据 动态数据就是个性化/高频写数据 阅读全文
摘要：
【IT老齐051】动态通知方案Push和Pull 场景 对比 Push模式 Pull模式 实时性 较好，通过网络管道准实时发送 较差，取决于定时轮询时间 服务器状态 有状态，需持久化粉丝动态队列 无状态，根据请求实时查询 风险项 大V动态的并发“写扩散”问题 大量动态队列持久化造成磁盘高 IO 大量 阅读全文
摘要：
【IT老齐050】MySQL服务器选择 CPU MySQL5.6以后版本对多核CPU进行优化 不支持多CPU对同一SQL并发处理 64位的CPU一定要工作在64位的系统下 对于并发比较高的场景CPU的数量比频率重要 对于CPU密集性场景和复杂SQL则频率越高越好 内存 理想的选择是服务器内存大于数据 阅读全文