AlbenXie的博客

转载 服务端高并发分布式架构演进之路

1. 概述本文以淘宝作为例子，介绍从一百个到千万级并发情况下服务端的架构的演进过程，同时列举出每个演进阶段会遇到的相关技术，让大家对架构的演进有一个整体的认知，文章最后汇总了一些架构设计的原则。特别说明：本文以淘宝为例仅仅是为了便于说明演进过程可能遇到的问题，并非是淘宝真正的技术演进路径2. 基本概念在介绍架构之前，为了避免部分读者对架构设计中的一些概念不了解，下面对几个最基础的概念进行介绍：分布式 系统中的多个模块在不同服务器上部署，即可称为分布式系统，如Tomcat和数据库分别部署

转载 警惕软件复杂度困局

简介：对于大型的软件系统如互联网分布式应用或企业级软件，为何我们常常会陷入复杂度陷阱？如何识别复杂度增长的因素？在代码开发以及演进的过程中需要遵循哪些原则？本文将分享阿里研究员谷朴关于软件复杂度的思考：什么是复杂度、复杂度是如何产生的以及解决的思路。较长，同学们可收藏后再看。写在前面软件设计和实现的本质是工程师相互通过“写作”来交流一些包含丰富细节的抽象概念并且不断迭代过程。另外，如果你的代码生存期一般不超过6个月，本文用处不大。一 软件架构的核心挑战是快速增长的复杂性越是...

转载 常见代码重构技巧，非常实用

关于重构为什么要重构项目在不断演进过程中，代码不停地在堆砌。如果没有人为代码的质量负责，代码总是会往越来越混乱的方向演进。当混乱到一定程度之后，量变引起质变，项目的维护成本已经高过重新开发一套新代码的成本，想要再去重构，已经没有人能做到了。造成这样的原因往往有以下几点：编码之前缺乏有效的设计 成本上的考虑，在原功能堆砌式编程 缺乏有效代码质量监督机制对于此类问题，业界已有有很好的解决思路：通过持续不断的重构将代码中的“坏味道”清除掉。什么是重构重构一书的作者Martin..

转载 JAVA线上故障排查全套路

线上故障主要会包括cpu、磁盘、内存以及网络问题，而大多数故障可能会包含不止一个层面的问题，所以进行排查时候尽量四个方面依次排查一遍。同时例如jstack、jmap等工具也是不囿于一个方面的问题的，基本上出问题就是df、free、top 三连，然后依次jstack、jmap伺候，具体问题具体分析即可。一、CPU一般来讲我们首先会排查cpu方面的问题。cpu异常往往还是比较好定位的。原因包括业务逻辑问题(死循环)、频繁gc以及上下文切换过多。而最常见的往往是业务逻辑(或者框架逻辑)导致的，可以使用js

转载 图解+代码|常见限流算法以及限流在单机分布式场景下的思考

大家好，我是 yes。今天来说说限流的相关内容，包括常见的限流算法、单机限流场景、分布式限流场景以及一些常见限流组件。当然在介绍限流算法和具体场景之前我们先得明确什么是限流，为什么要限流？。任何技术都要搞清它的来源，技术的产生来自痛点，明确痛点我们才能抓住关键对症下药。限流是什么？首先来解释下什么是限流？在日常生活中限流很常见，例如去有些景区玩，每天售卖的门票数是有限的，例如 2000 张，即每天最多只有 2000 个人能进去游玩。题外话：我之前看到个新闻，最不想卖门票的景区“

转载 springboot实现定时任务,异步操作,统一结果返回,全局异常处理,拦截器及事务处理

本文都是springboot的常用和实用功能,话不多说开始吧定时任务1.启动类开启注解@EnableScheduling //开启基于注解的定时任务@MapperScan("com.pdzx.dao")@SpringBootApplicationpublic class VideoApplication { public static void main(String[] args) { SpringApplication.run(VideoApplicatio

原创 聊聊微服务架构及分布式事务解决方案

分布式事务场景如何设计系统架构及解决数据一致性问题，个人理解最终方案把握以下原则就可以了，那就是：大事务=小事务（原子事务）+异步（消息通知），解决分布式事务的最好办法其实就是不考虑分布式事务，将一个大的业务进行拆分，整个大的业务流程，转化成若干个小的业务流程，然后通过设计补偿流程从而考虑最终一致性。什么是事务事务（Transaction）及其ACID属性事务是由一组SQL语句组成的逻...

转载 Java线程池实现原理及其在美团业务中的实践

随着计算机行业的飞速发展，摩尔定律逐渐失效，多核CPU成为主流。使用多线程并行计算逐渐成为开发人员提升服务器性能的基本武器。J.U.C提供的线程池ThreadPoolExecutor类，帮助开发人员管理线程并方便地执行并行任务。了解并合理使用线程池，是一个开发人员必修的基本功。本文开篇简述线程池概念和用途，接着结合线程池的源码，帮助读者领略线程池的设计思路，最后回归实践，通过案例讲述使用线程...

转载 Synchronized 和 Lock 锁在JVM中的实现原理以及代码解析

一、深入JVM锁机制：synchronizedsynrhronized关键字简洁、清晰、语义明确，因此即使有了Lock接口，使用的还是非常广泛。其应用层的语义是可以把任何一个非null对象作为"锁"，当synchronized作用在方法上时，锁住的便是对象实例（this）；当作用在静态方法时锁住的便是对象对应的Class实例，因为Class数据存在于永久带，因此静态方法锁相当于该类的一个全局锁...

转载 一文带你理解Java中Lock的实现原理

当多个线程需要访问某个公共资源的时候，我们知道需要通过加锁来保证资源的访问不会出问题。java提供了两种方式来加锁，一种是关键字：synchronized，一种是concurrent包下的lock锁。synchronized是java底层支持的，而concurrent包则是jdk实现。关于synchronized的原理可以阅读再有人问你synchronized是什么，就把这篇文章发给他。在这里...

转载 业务复杂=if else？刚来的大神竟然用策略 工厂彻底干掉了他们！

对于业务开发来说，业务逻辑的复杂是必然的，随着业务发展，需求只会越来越复杂，为了考虑到各种各样的情况，代码中不可避免的会出现很多if-else。一旦代码中if-else过多，就会大大的影响其可读性和可维护性。首先可读性，不言而喻，过多的if-else代码和嵌套，会使阅读代码的人很难理解到底是什么意思。尤其是那些没有注释的代码。其次是可维护性，因为if-else特别多，想要新加一个分...

转载 常见API网关总结分析

有一些特性Kong默认是缺失的，如API级别的超时、重试、fallback策略、缓存、API聚合、ABTest等，这些需要开发者自己定制和扩展。Kong是一个可扩展的，开源的API层，运行在RESTful前端，可通过插件扩展（认证、安全、流量控制、分析&监控、转换、日志）。常见的API网关有SpringGateway、Zuul、Kong、apisix等，基于nginx平台的网关有：KONG、APIUmbrella、apisix, 自研的网关有：apigee、StrongLoop、Zuul、Tyk。

转载 API网关之Kong网关简介

那么，Kong是一个什么东东呢？它是一个开源的API网关，或者你可以认为它是一个针对API的一个管理工具。你可以在那些上游service之上，额外去实现一些功能。Kong是开源的，所以你可以在Github找到它，你现在就可以下载使用。Kong是一款基于OpenResty（Nginx + Lua模块）编写的高可用、易扩展的，由Mashape公司开源的API Gateway项目。

转载 4层负载均衡和7层负载均衡，有什么区别

常见的负载均衡方式有几种，比如DNS，这是最简单的负载均衡的方式，一般用于实现地理级别的负载均衡。不同地域的用户通过DNS解析可以返回不同的IP地址，这种方式负载均衡最简单，但是扩展性太差，控制权在域名服务商。所以，4层负载均衡和7层负载均衡的区别在于他们所操作的网络层次不同。4层负载均衡工作在传输层，可以根据端口号IP地址进行负载均衡，但无法识别应用层的协议。作为网络层和传输层的模式，也被称作为4层负载均衡，通过对数据包的IP地址和端口进行修改，来达到负载均衡的效果。4层负载均衡和7层负载均衡有何不同？

转载 并行和并发哪个好?并行和并发的概念和区别

并发（concurrency）：指在同一时刻只能有一条指令执行，但多个进程指令被快速的轮换执行，使得在宏观上具有多个进程同时执行的效果，但在微观上并不是同时执行的，只是把时间分成若干段，使多个进程快速交替的执行。并行在多处理器系统中存在，而并发可以在单处理器和多处理器系统中都存在，并发能够在单处理器系统中存在是因为并发是并行的假象，并行要求程序能够同时执行多个操作，而并发只是要求程序假装同时执行多个操作（每个小时间片执行一个操作，多个操作快速切换执行）。2.跨多线程的并行工作可以更好的利用系统的资源。

转载 通俗易懂地理解并发和并行的区别

并发和并行的区别，相信很多初出茅庐的程序员都会被问到这个问题吧，这两个概念极容易混淆。今天，我们就来通俗地聊聊并发和并行的区别。

转载 多线程就一定能提高处理速度吗？

当程序偏计算型的时候，盲目启动大量线程来并发，并不能提高处理速度，反而会降低处理速度。因为在多个线程进行切换执行的时候会带会一定的开销。其中有 上下文切换开销，CPU调度线程的开销，线程创建和消亡的开销等。从输入结果来看，线程1K，10K的时候，多线程并没有打来处理效率的提升，反而下降了。上下文切换的开销，主要是来自于当线程切换时保存上一个线程现场和载入下一个线程现场的操作。使用多线程来提高程序处理速度，其本质是提高对CPU的利用率。使用空循环来模拟计算性任务，看下在不同数量的线程，程序的表现。

转载 吃透 MQ 的本质

这篇文章从 MQ 一发一存一消费这个本质出发，讲解了消息模型的演进过程，这是 MQ 最核心的理论基础。基于此，大家也能更容易理解 MQ 的各种新名词以及应用场景。最后通过回答：如何设计一个 MQ？目的是让大家对 MQ 的核心组件和技术难点有一个清晰的认识。另外，带着这个问题的答案再去学习 Kafka、RocketMQ 等具体的消息中间件时，也会更有侧重点。

转载 从0到1搭建车企数字化营销中台：客户数据平台

广义的CDP是一个营销系统，它统一企业来自营销或其他渠道的客户数据，以实现客户建模、优化客户体验的目标。狭义的CDP是整合来自多个不同来源的数据，为客户洞察和交互提供数据支持。

转载 OneID：实现全域链接、标签萃取、立体画像的数据应用服务

加密），缺少一句过渡。在动态识别算法之前，建设自动化数据接入框架，一方面ID所涉及的数据源业务的变更频繁，关系对接入需要不断调整，如某业务日志中的Mobile-MAC关系对需要添加，同时删除此日志中的MAC-UserID的关系等等，另外一方面因计算量实在太大影响数据产出时效，不是所有的ID和ID的识别都是支持的，因此需要有一个配置化的方式来记录哪些ID需要接入，哪些ID和ID之间需要识别服务。当时，作为数据服务团队一员，老板是甘云锋（风剑），按当时“用数据”的阶段定义，阿里巴巴正处于向3.0转变的过程，

转载 数据中台OneID：详解ID-Mapping！

相同设备，不同账号间切换相同用户，不同渠道下账号不相同，如微信小程序和APP同个用户，在不同的设备商登录ID-Mapping是大数据分析中非常基本但又关键的环节，ID-Mapping通俗的说就是把几份不同来源的数据，通过各种技术手段识别为同一个对象或主题，例如同一台设备（直接），同一个用户（间接），同一家企业（间接）等等，可以形象地理解为用户画像的“拼图”过程。

转载 数据库设计三大范式（简单易懂）

比如某些数据库系统中需要用到“地址”这个属性，本来直接将“地址”属性设计成为一个数据库表的字段就行，但是如果系统经常访问“地址”属性中的“城市”部分，那么一定要把“地址”这个属性重新拆分为省份、城市、详细地址等多个部分来进行存储，这样对地址中某一个部分操作的时候将非常方便，这样设计才算满足数据库的第一范式。这里产生一个问题：这个表中是以订单编号和商品编号作为联合主键，这样在该表中商品名称、单位、商品价格等信息不与该表的主键相关，而仅仅是与商品的编号相关，所以在这里违反了第二范式的设计原则。

转载 数据库设计的三大范式

3nf举例子：已经有课程表（课程编号、课程名称、课程时长）现在学生信息表也要有课程的信息，也想要有课程名称，但是根据第三范式是不允许直接在学生信息表出现课程名称（非主键），可以通过主键的课程编号间接拥有课程名称。数据库设计的三大范式。

转载 实现数据库中加密字段的模糊检索思路

如果输入01234 大于4位的号码，先将其分组，0123,1234，并将分组后的字符串分别加密，然后拼接在一起，做为sql语句的条件 like %smphone%不可以或不建议了，以目前4位分组来说，不能少于3位号码进行搜索了，分组太多，效率过低。诸如，把数据库数据先解密为明文在对比数据检索，或者把数据返给前端，让前端做数据对比与检索，都不是一个好的解决思路，结合具体业务细节上考虑的更多。可以的，如果输入3位号码，可以在后面+1位，分别为0-9，分为10组，进行检索。以此类推，实现对手机号的模糊检索。

转载 有状态服务和无状态服务

这类服务在网易蜂巢云平台创建后，借助k8s内部的负载均衡，当访问该服务的请求到达服务一端后，负载均衡会随机找到一个实例来完成该请求的响应（目前为轮询）。这类服务的实例可能会因为一些原因停止或者重新创建（如扩容时），这时，这些停止的实例里的所有信息（除日志和监控数据外）都将丢失(重启容器即会丢失)。是指该服务的实例可以将一部分数据随时进行备份，并且在创建一个新的有状态服务时，可以通过备份恢复这些数据，以达到数据持久化的目的。有状态服务只能有一个实例，因此不支持“自动服务容量调节”。

转载 Elasticsearch 有什么特点及应用场景？还有倒排索引，你有了解么

Elasticsearch 是分布式搜索和分析引擎。Elasticsearch 为所有类型的数据提供近实时（near real-time）的搜索和分析。网站搜索ELK 日志采集，存储，分析地理信息系统分析ES是一个分布式文档存储，存储的数据都是序列化为 JSON documents。使用倒排索引存储数据，倒排索引比较适合全文本搜索。基于搜索引擎库，可以存储，检索文档及元数据。支持 JSON 样式的查询语言 —— Query DSL，也支持 SQL 样式的查询。集群部署，易于扩展。

原创 Skywalking 集群安装

Skywalking 集群安装_skywalking集群搭建-CSDN博客

原创 kafka：生产者发送消息的分区策略

自定义分区策略 跟DefaultPartitioner实现方式一样。1、创建一个类，实现Partitioner接口。2、重写 partitioner中的方法，partitioner()方法的参数说明：参数1：topic参数2：key值参数3：key值字节数组参数4：value数据参数5：value数据的字节数组参数6：集群对象3、在 partitioner() 方法中编写自定义分区逻辑，返回分区编号。4、在生产者配置信息中进行配置自定义分区：=配置类全路径@Component。

原创 「RocketMQ技术专题」帮你梳理RocketMQ/Kafka的选择理由及二者PK

https://www.toutiao.com/article/7029921239707795976/?log_from=60a4a26619dc7_1699107228726

原创 kafka系列综述

https://www.cnblogs.com/xyqlrjm/p/14938673.html?log_from=433bd6c5241a2_1699107215470

原创 分布式定时任务调度框架选型

分布式定时任务调度框架选型-腾讯云开发者社区-腾讯云

原创 分布式链路追踪原理详解及SkyWalking、Zipkin介绍

分布式链路追踪原理详解及SkyWalking、Zipkin介绍-腾讯云开发者社区-腾讯云

原创 厉害！40 张图看懂分布式追踪系统原理及实践

https://www.toutiao.com/article/6871252505724977678/?log_from=1263c3b4dd6a_1699107151787

转载 什么是分布式锁？为什么要用分布式锁？

前面普通锁的使用堆内存中的变量的方式肯定不适用了。普通的锁，即在单机多线程环境下，当多个线程需要访问同一个变量或代码片段时，被访问的变量或代码片段叫做临界区域，我们需要控制线程一个一个的顺序执行，否则会出现并发问题。我们在开发应用的时候，如果需要对某一个共享变量进行多线程同步访问的时候，可以使用我们学到的Java多线程的18般武艺进行处理，并且可以完美的运行，毫无Bug！在单机多线程的java程序中，我们可以使用堆内存中的变量作为标志，因为多线程是共享堆内存的，堆内存中的变量对于各个线程都是可见的。

转载 为什么要用分布式锁？分布式锁的实现？

为什么要用锁？为什么要用分布式锁？首先带着标题的两个问题，为什么要用锁？为什么要用分布式锁？第一：为什么要用锁，很简单就一句话保证数据的安全性。在单机系统中，如果有多个线程同时操作同一个资源，就会出现数据安全问题。在Java中AtomicInteger、AtomicBoolean等java.util.concurrent包下的类能够保证单机系统的数据安全，同时还可以配合synchronized，lock使用。第二：为什么要用分布式锁，因为现在大部分互联网系统都采用分布式部署，提升系统总体性能。

转载 为什么公司规定所有接口都必须加上分布式锁，你知道吗？

今天就给大家聊一个有意思的话题：每秒上千订单场景下，如何对分布式锁的并发能力进行优化？

原创 Idea创建Springboot项目后生成的各文件作用

demo.iml：每个导入Idea的项目都会生成，工程配置文件，里面是当前project的一些配置信息，删了会重新生成，但可能引起错误。.idea：存放项目的配置信息，包括历史记录，版本控制信息等，不可删除，可隐藏。.gitignore： 使用git提交忽略文件配置，不用git可删除，可隐藏。mvnw.cmd：Windows上处理Maven版本兼容问题的脚本，可删除。.mvn：关于maven的配置信息，不可删除，可隐藏。HELP.md：一种文档格式，项目的帮助文档，可删除。

转载 万字解读Java线程-AtomicInteger原子类实现原理

上面的代码并非线程安全的，问题主要出现在count变量的不可见性和count+=1并非原子性操作，之前的解决方式都是使用Synchronized或者java sdk加锁的方式来保证原子性，使用volatile来保证可见性。在java线程-Lock详解&AQS原理详解一文中，发现大量使用了自旋+CAS操作，来保证线程安全性，这是一种无锁的操作，性能会比加锁的方式高很多。

转载 分布式事务最经典的七种解决方案！

本文介绍了分布式事务的一些基础理论，并对常用的分布式事务方案进行了讲解，在文章的后半部分还给出了事务异常的原因、分类以及优雅的解决方案。

转载 kafka常见问题