959

Redission实现分布式锁

MySQL 数据同步 Elasticsearch 的技术方案选型

跨域的3种解决方案: 1.CrossOrigin 2.HttpClient 3.SpringCloud Gateway

主主架构和主从架构和主备架构的区别

DDD 领域驱动设计 之 贫血和充血模式

设计一个RPC系统的步骤

优惠卷的设计系统

java开发注意事项 (三)

红包系统的设计

短链接设计

红包设计模式

Spring Event 解耦业务

何为设计容量，从技术上说就是运用一些策略对系统容量进行预估的过程。数据量、并发量、带宽、注册用户规模、活跃用户规模、在线用户规模、消息长度，图片大小、网盘空间容量，内存CPU容量等。1.分析过程TPS（Transactions Per Second）：每秒事务数QPS（Query Per Second）：每秒请求数，QPS其实是衡量吞吐量的一个常用指标，就是说服务器在一秒的时间内处理了多少个请求。并发数：并发数是指系统同时能处理的请求数量，这个也是反应了系统的负载能力。峰值QPS计算原理：每天

数据脱敏

单库单应用模式内容分发模式查询分离模式微服务模式多级缓存模式分库分表模式弹性伸缩模式多机房模式

文章目录1.InnoDB系统自增row_id2.Xid3.Innodb trx_id4.thread_id5.Redis自增主键6.总结1.InnoDB系统自增row_id如果你创建的 InnoDB 表没有指定主键，那么 InnoDB 会给你创建一个不可见的，长度为 6 个字节的 row_id。InnoDB 维护了一个全局的 dict_sys.row_id 值，所有无主键的 InnoDB 表，每插入一行数据，都将当前的 dict_sys.row_id 值作为要插入数据的 row_id，然后把 dict_

1.简单定时任务2.监听器3.收集日志4.excel导入5.查询接口6.获取用户上下文8.传递参数9.模拟高并发10.处理mq消息11.统计数量12.延迟定时任务 .

1.从 DDD 的角度看 MVC 架构的问题代码角度：瘦实体模型：只起到数据类的作用，业务逻辑散落到 service，可维护性越来越差面向数据库表编程，而非模型编程

文章目录1.现有数据存在的问题1.1 开发数据服务门槛高1.2 重复开发数据服务2. 系统架构2.1 大数据服务化业务架构2.2 大数据服务化技术架构1.现有数据存在的问题1.1 开发数据服务门槛高数据开发工程师除了开发完数据表外，通常还需要思考如下问题：数据如何交付：业务通常期望使用数据接口方式来使用数据，而非数据表，这会更加灵活、解耦、高效。数据开发工程师因此需要建立对应的数据服务服务如何开发：数据服务有多种形式，通常要求开发工程师有微服务知识、服务发现注册、高并发等权限、可用性

服务如何注册consumer如何知道provider服务注册中心如何高可用服务上下线，消费端如何动态感知文章目录1.服务注册2.服务消费3.注册中心高可用4.动态感知服务上下线1.服务注册当我们把服务信息注册上去后，就应该是：服务列表保存通常有三种方式：本地内存、数据库、第三方缓存系统注册上去后，consumer需要服务地址的时候，就可以用相应key去注册中心获取对应的服务列表。同一个服务注册中心，我们可以注册多个服务，比如用户服务、商品服务、订单服务…2.服务消费consum.

1.RPC 架构2.同步异步调用3.流行的 RPC 框架文章目录1.RPC 架构2.同步调用与异步调用3.流行的 RPC 框架4.HTTP 服务5.总结1.RPC 架构先说说 RPC 服务的基本架构吧。我们可以很清楚地看到，一个完整的 RPC 架构里面包含了四个核心的组件。ClientServerClient StubServer Stub（这个Stub大家可以理解为存根）客户端（Client），服务的调用方。服务端（Server），真正的服务提供者。

MySQL 登录密码，Redis 登录密码以及第三方的密钥等等一览无余。这里介绍一个加解密组件，提高一些属性配置的安全性。文章目录1.引入包2.配置加密、解密的密码3.测试用例中生成加密后的秘钥4.将加密后的字符串替换原明文5.部署时配置 salt（盐）值1.引入包<dependency> <groupId>com.github.ulisesbocchio</groupId> <artifactId>jasypt-spring-boot

文章目录1.缓存雪崩2.缓存穿透3.缓存击穿4.数据不一致5.数据并发竞争6.热点key问题7.BigKey问题1.缓存雪崩指缓存同一时间大面积的失效，所以，后面的请求都会落到数据库上，造成数据库短时间内承受大量请求而崩掉。解决方案：Redis 高可用，主从+哨兵，Redis cluster，避免全盘崩溃本地 ehcache 缓存 + hystrix 限流&降级，避免 MySQL 被打死缓存数据的过期时间设置随机，防止同一时间大量数据过期现象发生。逻辑上永不过期给每一个缓存数据增加相

如图是一个简化的下单流程，首先是提交订单，然后是支付。支付的话，一般是走支付网关（支付中心），然后支付中心与第三方支付渠道（微信、支付宝、银联）交互，支付成功以后，异步通知支付中心，支付中心更新自身支付订单状态，再通知业务应用，各业务再更新各自订单状态。这个过程中经常可能遇到的问题是掉单，无论是超时未收到回调通知也好，还是程序自身报错也好，总之由于各种各样的原因，没有如期收到通知并正确的处理后续逻辑等等，都会造成用户支付成功了，但是服务端这边订单状态没更新，这个时候有可能产生投诉，或者用户重复支付。由.

秒杀一般出现在商城的促销活动中，指定了一定数量（比如：10个）的商品（比如：手机），以极低的价格（比如：0.1元），让大量用户参与活动，但只有极少数用户能够购买成功。这类活动商家绝大部分是不赚钱的，说白了是找个噱头宣传自己。文章目录1.瞬时高并发2.页面静态化3.秒杀按钮1.瞬时高并发一般在秒杀时间点（比如：12点）前几分钟，用户并发量才真正突增，达到秒杀时间点时，并发量会达到顶峰。但由于这类活动是大量用户抢少量商品的场景，必定会出现狼多肉少的情况，所以其实绝大部分用户秒杀会失败，只有极少部分用.

如果实际生产有需求变更的话, 不会立刻在线上服务修改, 而是会切成一小部分流量进行修改测试。经过测试后无问题则全面的上线。文章目录1.什么是灰度发布2.什么是全链路灰度发布3.网关层的灰度路由转发4.openFeign透传灰度标记5.Nacos中服务如何做灰度标记6.总结1.什么是灰度发布灰度发布（又名金丝雀发布）是指在黑与白之间，能够平滑过渡的一种发布方式。在上面可以进行A/B测试, 即让一部分用户继续用产品特性A, 一部分用户使用产品特性B, 如果用户B没有反对意见的话, 那么会逐渐扩大范围, 把

文章目录1.系统正确性1.系统正确性

1. SimpleDateFormat线程不安全@Servicepublic class SimpleDateFormatService { public Date time(String time) throws ParseException { SimpleDateFormat dateFormat = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss"); return dateFormat.parse(time);.

文章目录1.原则一：价值为王2.原则二：以终为始3.原则三：分治原则4.原则四：服务自治5.原则五：拥抱变化6.原则六：简单即正义7.原则七：尽量自动化8.原则八：依赖最简9.原则九：不作不死10.原则十：容灾容错11.原则十一：用成熟的技术1.原则一：价值为王价值为王的另一种说法叫做YAGNI。YAGNI 是 You aren’t gonna need it 的缩写。该原则的基本含义就是，不应该开发任何当前不使用的功能。因为这些占用开发成本的功能，可能根本没有人用。而且不仅仅是开发成本打了水漂，你还.

文章目录1.哪些问题会引起接口性能问题2.问题解决2.1 慢查询（基于mysql）2.2 业务逻辑复杂2.3 线程池设计不合理2.4 锁设计不合理2.5 机器问题（fullGC，机器重启，线程打满）2.6 万金油解决方式1.哪些问题会引起接口性能问题数据库慢查询深度分页问题未加索引索引失效join过多子查询过多in中的值太多单纯的数据量过大业务逻辑复杂循环调用顺序调用线程池设计不合理锁设计不合理机器问题（fullGC，机器重启，线程打满）2.问题解决2.1 慢查询（基于

文章目录1.接口相互作用2.返回格式3.数据4.控制层控制器5.美观美化6.优雅优化7.其他优化方案1.接口相互作用前端和前端进行交互，前端按约定的请求URL路径，并合并相关参数，进入服务器接收请求，进行业务处理，返回数据给前端。2.返回格式{ #返回状态码 code:integer, #返回信息描述 message:string, #返回值 data:object}：下面是常见的HTTP状态码：200 - 请求成功301 - 资源（网页等）被永久转移到其它URL.

文章目录1.系统拆分2.解耦3.异步4.重试5.补偿6.备份7.多活策略8.隔离9.限流10.熔断11.降级1.系统拆分微服务架构，将一个复杂的业务域按DDD的思想拆分成若干子系统，每个子系统负责专属的业务功能，做好垂直化建设，各个子系统之间做好边界隔离，降低风险蔓延。2.解耦高内聚、低耦合。小到接口抽象、MVC 分层，大到 SOLID 原则、23种设计模式。核心都是降低不同模块间的耦合度，避免一处错误改动影响到整个系统。就以开闭原则为例，对扩展是开放的，对修改是关闭的。随着业务功能迭代，如何做到

文章目录1.ShardingSphere概念2.功能列表3.项目状态4.分库分表_结果归并1.ShardingSphere概念ShardingSphere是一套开源的分布式数据库中间件解决方案组成的生态圈，它由Sharding-JDBC、Sharding-Proxy 和 Sharding-Sidecar这3款相互独立的产品组成。他们均提供标准化的数据分片、分布式事务 和 数据库治理功能，可适用于如Java同构、异构语言、云原生等各种多样化的应用场景。Apache ShardingSphere 旨在充

文章目录1.订单中所包含的内容信息2.流程引擎2.1 正向流程2.1.1 订单创建2.1.2 订单支付2.1.3 订单生产2.1.4 订单确认2.1.5 订单完成2.2 逆向流程2.3 状态机3.订单系统的发展1.订单中所包含的内容信息为了使订单系统能够对订单进行高效、精准的管理和跟踪，订单会储存关于产品、优惠、用户、支付信息等一系列的订单实时数据，来和下游系统，如：促销、仓储、物流进行交互。以一个通用B2C商城的订单为例，梳理其包含的信息如下：这里要注意的是订单类型，随着平台业务的不断发展，品类

文章目录1.订单系统在企业中的角色2.订单系统与各业务系统的关系2.1 对外系统2.2 管理中后台2.3 公共服务系统3.订单系统上下游关系4.订单系统的业务架构4.1 订单服务4.2 订单逻辑4.3 底层服务1.订单系统在企业中的角色在搭建企业订单系统之前，需要先梳理企业整体业务系统之间的关系和订单系统上下游关系，只有划分清业务系统边界，才能确定订单系统的职责与功能，进而保证各系统之间高效简洁的工作。2.订单系统与各业务系统的关系2.1 对外系统所有给企业外部用户使用的系统都在这一层，包括官网

文章目录1.难题与方案2.具体措施2.1 页面静态化2.2 图片服务器分离2.3 数据库集群、库表散列1.难题与方案1、亿级流量电商网站的商品详情页系统架构面临难题：对于每天上亿流量，拥有上亿页面的大型电商网站来说，能够支撑高并发访问，同时能够秒级让最新模板生效的商品详情页系统的架构是如何设计的?解决方案：异步多级缓存架构+nginx本地化缓存+动态模板渲染的架构2、redis企业级集群架构面临难题：如何让redis集群支撑几十万QPS高并发+99.99%高可用+TB级海量数据+企业级数据备份与

1.数据库瓶颈不管是IO瓶颈，还是CPU瓶颈，最终都会导致数据库的活跃连接数增加，进而逼近甚至达到数据库可承载活跃连接数的阈值。在业务Service来看就是，可用数据库连接少甚至无连接可用。接下来就可以想象了吧（并发量、吞吐量、崩溃）。1.1 IO瓶颈第一种：磁盘读IO瓶颈，热点数据太多，数据库缓存放不下，每次查询时会产生大量的IO，降低查询速度 -> 分库和垂直分表。第二种：网络IO瓶颈，请求的数据太多，网络带宽不够 -> 分库。1.2 CPU瓶颈第一种：SQL问题，如SQL中包含

文章目录1.算法1.1 计数器法1.2 漏桶算法1.3 令牌桶算法1.4 滑动窗口算法2.单机限流器2.1 GUAVA RateLimiter限流器2.2 Java的 AtomicInteger2.3 Semaphore信号量3.分布式限流器3.1 redis作为分布式限流器3.2 Seentinel限流3.3 Hystric 限流4.接入层限流器4.1 nginx限流之限制请求4.2 nginx限流之限制连接数4.3 nginx限流之设置白名单1.算法计数器漏桶算法令牌桶算法滑动窗口算法1

文章目录1.负载均衡2.分布式微服务3.缓存机制4.分布式关系型数据库4.1 垂直分表4.2 水平分表4.3 开源框架分类4.4 实现方案5.分布式消息队列5.1 常见的消息队列5.2 消息队列的场景6.CDN 内容分发网络7.其他8.总结1.负载均衡靠优化单台机器的内存、CPU、磁盘、网络带宽，使其发挥极致性能，已经不太现实。负载均衡，它的职责是将网络请求 “均摊”到不同的机器上。避免集群中部分服务器压力过大，而另一些服务器比较空闲的情况通过负载均衡，可以让每台服务器获取到适合自己处理能力的负载。