架构系列

1 背景 业务线与系统越来越多，系统或业务间数据同步需求也越频繁。当前互联网业务系统大多MySQL数据存储与处理方案： 随信息时代爆炸，大数据量场景下慢慢凸显短板，如：需对大量数据全文检索，对大量数据

一 引子 有赞是提供商家SAAS服务，随着越来越多的商家使用有赞，越来越多的需求铺张而来，搜索或详情的需求会越来越多,针对需求及场景，之前提到过的订单管理架构演变及AKF架构等在这两篇文章里已经有所体

错误原理： “too many open files”这个错误大家经常会遇到，因为这个是Linux系统中常见的错误，也是云服务器中经常会出现的，而网上的大部分文章都是简单修改一下打开文件数的限制，根本

本文章向大家介绍Caffeine - Caffeine框架全介绍，主要内容包括总结、详细内容、1，概述、2，各种缓存综述、2.1， FIFO、2.2，LRU、2.3，LFU、2.4，Guava、3，C

一：什么是Redis 大Key 在Redis中，"big key" 指的是一个占用较多内存空间的键。当一个键的值占用的内存超过了Redis的配置阈值时，它就被认为是一个 "big key"。大的键可以

一. 什么是分库分表 二. 为什么需要分库分表 2.1 为什么需要分库呢？ 如果业务量剧增，数据库可能会出现性能瓶颈，这时候我们就需要考虑拆分数据库。从这⼏⽅⾯来看： 磁盘存储 业务量剧增，MySQL

概要 此文章基于阿里巴巴-王冬在”2021年5月29日Ocon软件大会第二天-大麦票务技术体系重塑演进之路”的演讲后做的个人总结。 一、分享内容的大概流程 1)这是一个高流量系统的重构经历。 2)这是

一： 需求 构建一个电商通用型商品中心，可支持商品的种类和属性繁多，可以售卖实物、虚拟、会员、服务类商品。每一种商品具有不同的规格，不同的规格的商品有多种价格，商品可支持多种货币的支付。

一、背景 大麦网作为现场娱乐票务平台，其业务覆盖了各大顶级演唱会和大型赛事等高流量项目。票务行业库存系统不同于普通电商库存系统，瞬压过高的秒杀抢票，多场景、多阶段的售卖，对一致性和稳定性提出更高要求。

1、方案 1.1 方案一：根据商品 id 查询库存，校验库存是否足够后，利用数据库自己的字段减法实现 set 扣减 缺点：并发问题导致两个线程同时查到一个库存，随后会发生后扣减的覆盖先扣减的执行结果。

场景说明 如果cpu在某些场景下，快速飙高/升，不易捕捉堆栈和线程信息，可以采用以下方法 脚本原理 脚本的原理说明，脚本通过cron定时任务，定时执行抓取Java应用的堆栈，线程信息。 脚本通过定时查

在现实场景中我们很可能在某些业务中配置很多优惠，但是优惠的计算逻辑一般相对复杂的有的要利用穷举，动态规划，广度优先分包，深度优先计算，再则利用贪心算法等等

在目前比较常见的网站中，首页、活动页、商品详情页等系绕承载了网站的大部分流量，而这些系统的主要职责包括数据的聚合拼裝、热点数据统计、缓存、下游功能降级开关、兜底数据等。其中数据聚合需要调用多个其他服务

也即是说一个选座类抢票就涉及 10 万级别的商品，如果多个项目同时开抢，整体数量会很庞大。目前主流演出平台侧的商品维度是票档，座位并不是商品粒度，其实演唱会抢票比常见电商链路更复杂涉及电商、选座、票务

在现有演出业务中，我们有这样一个场景，管理员在后台管理系统中可以对先有演出项目，场次，售卖时间，票种等信息进行修改，比如原先我有一个演出项目 “周杰伦演唱会”，这时候用户在C端就可以看到名称就是“周杰

Kafka 是一种高吞吐量、分布式、基于发布/订阅的消息系统，最初由 LinkedIn 公司开发，使用 Scala 语言编写，目前是 Apache 的开源项目，也是目前较为主流的消息列队。作用吗和其他

一、背景 今年开始，旅游以及娱乐行业加速了复苏，各种大型演唱会开始紧锣密鼓的举办，同时作为疫情后第一个五一出行人次再创新高，也造就了火车票一票难求的局面。无论是演唱会还是火车票抢票都是一个高并发的场景

觉得不错请按下图操作，掘友们，哈哈哈！！！ 概述 博主最近在做分布式事务这块业务，所以在选型的过程中，对比了当下比较流行的解决方案，在这里坐下记录，欢迎jym提出更好的方案哦。

觉得不错请按下图操作，掘友们，哈哈哈！！！ 一：背景         某个票务系统比如12306占座，演出等， 流量最高的业务场景是在查询座位图和锁座环节，新的票务系统在优化后用了新的扣位占座系统，同

一：前言 这套体系涉及的技术点⾮常多，不限于熔断、流控、异步、池化、背压、负载均衡、主从分离、读写分离、缓存雪 崩、缓存穿透、数据⼀致性、注册中⼼、配置中⼼、微服务等。 二：概述 本⽂以淘宝作为例⼦，