- 博客(2234)
- 资源 (1)
- 收藏
- 关注
RSS订阅
转载 服务端高并发分布式架构演进之路
1. 概述本文以淘宝作为例子，介绍从一百个到千万级并发情况下服务端的架构的演进过程，同时列举出每个演进阶段会遇到的相关技术，让大家对架构的演进有一个整体的认知，文章最后汇总了一些架构设计的原则。特别说明：本文以淘宝为例仅仅是为了便于说明演进过程可能遇到的问题，并非是淘宝真正的技术演进路径2. 基本概念在介绍架构之前，为了避免部分读者对架构设计中的一些概念不了解，下面对几个最基础的概念进行介绍：分布式 系统中的多个模块在不同服务器上部署，即可称为分布式系统，如Tomcat和数据库分别部署
2021-05-25 17:47:54
404
转载 警惕软件复杂度困局
简介：对于大型的软件系统如互联网分布式应用或企业级软件，为何我们常常会陷入复杂度陷阱？如何识别复杂度增长的因素？在代码开发以及演进的过程中需要遵循哪些原则？本文将分享阿里研究员谷朴关于软件复杂度的思考：什么是复杂度、复杂度是如何产生的以及解决的思路。较长，同学们可收藏后再看。写在前面软件设计和实现的本质是工程师相互通过“写作”来交流一些包含丰富细节的抽象概念并且不断迭代过程。另外，如果你的代码生存期一般不超过6个月，本文用处不大。一 软件架构的核心挑战是快速增长的复杂性越是...
2021-05-19 18:17:58
562
转载 常见代码重构技巧，非常实用
关于重构为什么要重构项目在不断演进过程中，代码不停地在堆砌。如果没有人为代码的质量负责，代码总是会往越来越混乱的方向演进。当混乱到一定程度之后，量变引起质变，项目的维护成本已经高过重新开发一套新代码的成本，想要再去重构，已经没有人能做到了。造成这样的原因往往有以下几点：编码之前缺乏有效的设计 成本上的考虑，在原功能堆砌式编程 缺乏有效代码质量监督机制对于此类问题，业界已有有很好的解决思路：通过持续不断的重构将代码中的“坏味道”清除掉。什么是重构重构一书的作者Martin..
2021-05-13 10:01:52
692
转载 JAVA线上故障排查全套路
线上故障主要会包括cpu、磁盘、内存以及网络问题，而大多数故障可能会包含不止一个层面的问题，所以进行排查时候尽量四个方面依次排查一遍。同时例如jstack、jmap等工具也是不囿于一个方面的问题的，基本上出问题就是df、free、top 三连，然后依次jstack、jmap伺候，具体问题具体分析即可。一、CPU一般来讲我们首先会排查cpu方面的问题。cpu异常往往还是比较好定位的。原因包括业务逻辑问题(死循环)、频繁gc以及上下文切换过多。而最常见的往往是业务逻辑(或者框架逻辑)导致的，可以使用js
2020-09-22 17:45:24
414
转载 图解+代码|常见限流算法以及限流在单机分布式场景下的思考
大家好，我是 yes。今天来说说限流的相关内容，包括常见的限流算法、单机限流场景、分布式限流场景以及一些常见限流组件。当然在介绍限流算法和具体场景之前我们先得明确什么是限流，为什么要限流？。任何技术都要搞清它的来源，技术的产生来自痛点，明确痛点我们才能抓住关键对症下药。限流是什么？首先来解释下什么是限流？在日常生活中限流很常见，例如去有些景区玩，每天售卖的门票数是有限的，例如 2000 张，即每天最多只有 2000 个人能进去游玩。题外话：我之前看到个新闻，最不想卖门票的景区“
2020-09-22 13:06:08
496
转载 springboot实现定时任务,异步操作,统一结果返回,全局异常处理,拦截器及事务处理
本文都是springboot的常用和实用功能,话不多说开始吧定时任务1.启动类开启注解@EnableScheduling //开启基于注解的定时任务@MapperScan("com.pdzx.dao")@SpringBootApplicationpublic class VideoApplication { public static void main(String[] args) { SpringApplication.run(VideoApplicatio
2020-08-26 20:22:41
1701
原创 聊聊微服务架构及分布式事务解决方案
分布式事务场景如何设计系统架构及解决数据一致性问题，个人理解最终方案把握以下原则就可以了，那就是：大事务=小事务（原子事务）+异步（消息通知），解决分布式事务的最好办法其实就是不考虑分布式事务，将一个大的业务进行拆分，整个大的业务流程，转化成若干个小的业务流程，然后通过设计补偿流程从而考虑最终一致性。什么是事务事务（Transaction）及其ACID属性事务是由一组SQL语句组成的逻...
2020-04-21 22:34:45
586
转载 Java线程池实现原理及其在美团业务中的实践
随着计算机行业的飞速发展，摩尔定律逐渐失效，多核CPU成为主流。使用多线程并行计算逐渐成为开发人员提升服务器性能的基本武器。J.U.C提供的线程池ThreadPoolExecutor类，帮助开发人员管理线程并方便地执行并行任务。了解并合理使用线程池，是一个开发人员必修的基本功。本文开篇简述线程池概念和用途，接着结合线程池的源码，帮助读者领略线程池的设计思路，最后回归实践，通过案例讲述使用线程...
2020-04-03 14:58:43
644
转载 Synchronized 和 Lock 锁在JVM中的实现原理以及代码解析
一、深入JVM锁机制：synchronizedsynrhronized关键字简洁、清晰、语义明确，因此即使有了Lock接口，使用的还是非常广泛。其应用层的语义是可以把任何一个非null对象作为"锁"，当synchronized作用在方法上时，锁住的便是对象实例（this）；当作用在静态方法时锁住的便是对象对应的Class实例，因为Class数据存在于永久带，因此静态方法锁相当于该类的一个全局锁...
2020-04-01 16:00:25
519
转载 一文带你理解Java中Lock的实现原理
当多个线程需要访问某个公共资源的时候，我们知道需要通过加锁来保证资源的访问不会出问题。java提供了两种方式来加锁，一种是关键字：synchronized，一种是concurrent包下的lock锁。synchronized是java底层支持的，而concurrent包则是jdk实现。关于synchronized的原理可以阅读再有人问你synchronized是什么，就把这篇文章发给他。在这里...
2020-04-01 15:04:40
868
转载 业务复杂=if else？刚来的大神竟然用策略 工厂彻底干掉了他们！
对于业务开发来说，业务逻辑的复杂是必然的，随着业务发展，需求只会越来越复杂，为了考虑到各种各样的情况，代码中不可避免的会出现很多if-else。一旦代码中if-else过多，就会大大的影响其可读性和可维护性。首先可读性，不言而喻，过多的if-else代码和嵌套，会使阅读代码的人很难理解到底是什么意思。尤其是那些没有注释的代码。其次是可维护性，因为if-else特别多，想要新加一个分...
2019-10-24 13:41:06
837
转载 架构师的七大核心能力
质量标准是质量保障的基础，架构师需要与研发、QA、产品一起，定义明确的质量标准。这些标准应涵盖系统的各个方面，包括功能性、性能、安全性、可用性、可维护性等。系统是否实现了预期的功能，是否满足了业务需求。架构师需要确保功能设计的合理性和完整性，并在开发过程中通过测试验证功能的实现。系统在高负载下的表现是否符合预期。架构师需要定义性能指标，如响应时间、吞吐量、资源利用率等，并通过性能测试验证系统的性能表现。系统是否具备应对安全威胁的能力，如防止数据泄露、抵御攻击等。
2024-09-20 21:05:39
446
转载 转转客服IM系统：高效沟通背后的技术挑战和解决方案
在当今互联网时代，高效的用户服务是提升用户体验的关键。转转自研的客服IM系统作为用户与客服沟通的桥梁，承担着传递信息、解决问题的关键角色。然而，消息数据的流转并非一帆风顺，本文将深入探讨IM系统在消息传递过程中遇到的问题和挑战，以及相应的技术解决方案。如图是IM系统中一条消息的流转链路：IM消息流转相较于普通web系统，IM系统的消息数据流转链路更长、更复杂。从客户端到服务端，再从服务端到另一个客户端，任何一个环节的故障都可能导致消息延迟、丢失、乱序或重复，从而影响用户体验。
2024-09-20 02:40:42
48
转载 MySQL亿级数据平滑迁移实战
在进行数据表迁移的过程中，虽然遇到了一些问题，但是制定的方案中每一步都有回退措施，即使出现问题也不会影响业务的正常运行。此外，笔者在迁移过程中对各种异常情况进行了监控，能及时发现并解决问题。迁移插件实现：在对迁移过程进行反思后，笔者人为通过代理或重写 MapperProxy 的方式来实现迁移插件可能是更加合理的方案。这种方案有两个优点：一方面，可以避免处理 Mybatis 复杂的参数转换流程，从而减少潜在的错误和异常；另一方面，可以实现先写新库再异步写老库的操作。
2024-09-20 02:30:50
172
转载 高效接口背后的秘密：高并发接口优化指南
确保系统稳定性是开发的关键目标之一，通过定期对系统进行全面监控和性能指标分析，能够有效识别出潜在的系统性风险。通过对一次简单的调整，就可能显著提升系统的整体性能和响应能力。
2024-09-20 02:17:52
87
转载 数据库常见死锁产生的原因及解决方案
2、使用乐观锁进行控制。需要注意的是，由于乐观锁机制是在我们的系统中实现，来自外部系统的用户更新操作不受我们系统的控制，因此可能会造 成脏数据被更新到数据库中。如一个金融系统， 当某个操作员读取用户的数据，并在读出的用户数据的基础上进行修改时（如更改用户账户余额），如果采用悲观锁机制，也就意味着整个操作过程中（从操作员读 出数据、开始修改直至提交修改结果的全过程，甚至还包括操作员中途去煮咖啡的时间），数据库记录始终处于加锁状态，可以想见，如果面对成百上千个并发，这 样的情况将导致灾难性的后果。
2024-09-20 02:10:59
40
转载 MySQL事务死锁问题排查
在预发环境中，由消息驱动最终触发执行事务来写库存，但是导致 MySQL 发生死锁，写库存失败。初步排查，在同一时刻有两条请求进行写库存的操作。时间前后相差 1s，但最终执行结果是，这两个事务相互死锁，均失败。所使用的数据库引擎为 Innodb，隔离级别为 RR [Repeatable Read] 可重复读。。
2024-09-20 01:59:41
154
转载 MySQL之死锁问题及其解决方案
数据库死锁问题是我们老生常谈的问题了，在我们实际开发过程中经常会遇到，为了尽量避免出现死锁，我们需要了解出现死锁的场景。同时，如果线上出现了死锁之后怎么去分析、排查和解决，下面我就这两点介绍一下。不同的事务在获取资源时相互等待，导致无法继续执行的一种情况。当发生死锁时，数据库系统会自动中断其中一个事务，以解除死锁。在数据库中，事务可以分为读事务和写事务。读事务只需要获取读锁，而写事务需要获取写锁。当多个事务同时操作同一组数据时，可能会引发死锁的出现。
2024-09-20 01:46:29
58
转载 分析SQL执行计划，需要关注哪些重要信息
一个执行计划中，共有 12 个字段，每个字段都十分重要。：执行计划中每个操作的独特标识符。对于一条查询语句，每个操作都有其唯一的 id。然而，在多表连接时，一次解释中的多个记录可能具有相同的 id。：操作的种类。常见种类包括 SIMPLE、PRIMARY、SUBQUERY、UNION 等。不同种类的操作会影响查询的执行效率。：当前操作所涉及的表。：当前操作所涉及的分区。：表示查询时所使用的索引类型，包括 ALL、index、range、ref、eq_ref、const 等。
2024-09-20 01:39:10
48
转载 聊聊order by 是怎么实现的？
首先排序功能由 ORDER BY 实现，具体排列顺序取决于优化器的选择。若优化器认为索引排序更有效率，则使用索引排序；反之，则使用 filesort（执行计划中额外信息提示：使用 filesort）。然而，索引排序的适用情况有限，且不确定性较高，通常还是会采用 filesort。在 filesort 排序中，如果排序的数据较少，可在内存中的 sort_buffer 上完成；否则，需借助临时文件进行排序。实际排序过程中，如果字段长度较短，可直接在 sort_buffer 中进行全字段排序并返回结果集。
2024-09-20 01:36:48
14
转载 ✅难得真实的生产数据库死锁问题排查过程
在死锁发生后的一周内，我几乎每天都会抽空进行研究。问题很早就被定位到了，并且修改方案也已经有了，但是其中的原理一直没有搞清楚。我做过很多种推断和假设，但每一次都被自己推翻。最终，我意识到还是需要通过实践来验证我的想法。因此，我在本地安装了数据库，在实际操作中进行了多次测试，并实时查看数据库的锁情况。使用命令可以查看详细的锁信息。最终，我才彻底搞清楚了背后的原理。遇到问题时，不要仅凭猜测！重要的是亲自复现问题，然后再进行分析。不要忽视上下文！
2024-09-20 01:33:41
108
转载 ✅线上紧急问题之Using filesort 能优化吗，怎么优化？
上一篇文章中，提到了如何分析 SQL 的执行计划，从而更好的应对 SQL 性能过低等问题。但是我们也常遇到Extra字段是的时候，上篇文章有描述：在 InnoDB 存储引擎中，当执行计划中出现"Using filesort"时，表示 MySQL 需要对结果集进行外部排序，以满足查询中的 ORDER BY 条件。比如，下面这个执行计划中的"Extra"部分出现了"Using filesort"，表明需要进行文件排序。代码语言：sql在下面这篇文章中，我们已经介绍了 ORDER BY 的实现原理。
2024-09-20 01:28:33
75
转载 MySQL隔离级别 、锁机制-面试
事务id，在mysql内部是全局唯一递增的，事务id=1，事务id=2，事务id=3 在一个事务内查询的时候，mysql只会查询创建时间的事务id小于等于当前事务id的行，这样可以确保这个行是在当前事务中创建，或者是之前创建的；这样的话，你的这个事务其实对某行记录的查询，始终都是查找的之前的那个快照，因为之前的那个快照的创建时间小于等于自己事务id，然后删除事件的事务id比自己事务id大，所以这个事务运行期间，会一直读取到这条数据的同一个版本。适用于数据读取远远多于数据更新的场景，减少锁的开销。
2024-09-20 01:23:12
93
转载 解决数据库死锁问题
死锁是指两个或两个以上的进程（或线程）在执行过程中，由于竞争资源或者彼此通信而造成的一种阻塞现象。在无外力作用下，它们都无法继续向前推进。这种状态被称为系统处于死锁状态，或者简称系统发生了死锁。这些相互等待的进程被称为死锁进程。比如，丈母娘要求先买房才能结婚，但女婿坚持要先结婚再买房，这种情况类比了死锁的概念。
2024-09-20 00:54:35
36
转载 Flink CDC 在货拉拉的落地与实践
今天的文章撰写自陈政羽老师在 Apache Asia Community Over Code 2024 上的分享《货拉拉在 Flink CDC 生产实践落地》，系统地介绍货拉拉的业务背景，技术选型，整体能力构建与收益，最后分享了开源参与以及开展的未来工作和期望。
2024-09-19 00:44:30
155
转载 因果推断在转转推荐场景下的实践
因果关系是一种普遍的关系，描述的是结果和产生这个结果的原因之间的关联。在因果关系中，因是导致事件发生的条件或行为，果则是这个原因导致的结果或变化。我们平时生活中到处都存在着因果问题，上大学是否会带来更多收入？直觉上我们认为高等教育会增加个人收入，但我们却很难说清楚没有上过大学的人如果上了大学会增加多少收入，同时我们也有看到没上过大学也能赚大钱的人。我们常常会想，如果某一时刻做了另外的选择，是否生活会变得完全不一样呢。
2024-09-19 00:33:41
76
转载 状态机：从传统的 if-else 到高效的状态管理
状态机（State Machine）是一种数学模型，用于描述系统状态以及在这些状态之间的流转和动作等行为。一般情况下，我们讨论的状态机的状态个数是有限的，即有限状态机（Finite State Machine, FSM）。状态（State）：系统可能处于的不同状态，如开、关等。事件（Event）：导致状态流转的触发事件，如按钮点击。动作（Action）：事件发生之后要执行的动作。流转（Transition）：从一个状态到另一个状态的过渡。
2024-09-19 00:24:08
61
转载 架构师必备底层逻辑：分层架构设计
同样 DDD 微服务的标准分层如上图，微服务有一个核心概念叫做独立自治的领域， 领域层要尽量少的依赖领域外的东西，才能够足够的稳定，满足越底层越稳定的依赖的要求，但这样的设计容易走到了贫血模型的模式，有 DDD 的概念，却没有 DDD 的实际作用。此处我们举个数据仓库设计的例子，标准的数仓设计分层原则如下：在数仓中，包含 dwd（从流水表中清洗的数据，主要是非法数据过滤，格式转换等），dwm（轻度聚合多维度group by)， dm（面向主题层，包含指标和维度），app（高阶的统计数据，可出库到报表）。
2024-09-19 00:10:52
136
转载 产品经理的15种思维模型
产品画布分为两大部分，产品以及市场，从1-9可以很好地帮助构建产品框架，从问题出发，寻找用户，找出产品独特卖点，给出解决方案，从市场层面给出渠道和手段营销，进行数据分析（成本，收益，关键指标等等），最后去确立自己独特的竞争优势，建立自己的护城河。”确立产品的方向和目标，确保产品能够满足用户的需求并实现公司的商业目标。大家好，我是月亮，深耕B端多年，总结了很多对大家日常工作比较有帮助的产品思维模型，可以更好地帮助我们去分析需求，分析市场环境，更好地制定产品策略和公司发展方向，更好地管理产研进程。
2024-09-18 23:59:44
61
转载 架构设计的悖论，复用是美好的还是邪恶的
错误的抽象、错误的代码复用，所引发的复杂性无限蔓延，对系统的危害比面条代码强大一百倍。复用与扩展，业务与技术，到底哪些该复用哪些不该复用，好像变成了一个哲学问题。如果说“正确的抽象”是一个100分的美丽乌托邦，那面向复杂性隔离的整洁架构，会不会是一个稳定的80分。面向复杂性隔离的整洁架构，我好像有了一些新的想法... To Be Continue。
2024-09-18 23:16:33
75
转载 从零开始搭建创业公司后台技术栈
说到后台技术栈，脑海中是不是浮现的是这样一幅图？[图1]有点眼晕，以上只是我们会用到的一些语言的合集，而且只是语言层面的一部分，就整个后台技术栈来说，这只是一个开始，从语言开始，还有很多很多的内容。今天要说的后台是大后台的概念，放在服务器上的东西都属于后台的东西，比如使用的框架，语言，数据库，服务，操作系统等等，整个后台技术栈我的理解包括4个层面的内容：语言： 用了哪些开发语言，如：c++/java/go/php/python/ruby等等；组件：用了哪些组件，如：MQ组件，数据库组件等等；
2024-09-18 00:58:49
1481
转载 互联网创业中的日志系统选型
染色体系 给每一次请求加上一个全局的logid（id全局唯一，最好是能根据id定位到业务或用户，比如业务编号+用户编号+时间戳+随机数），每次记日志的时候，logid打出来，所有底层的框架在调用的时候，需要在公共属性部分将这个logid传过去，打印的所有日志都要带上这个logid。这样所有的业务，所有的服务，不管有多少系统，有多少机器，在处理同一请求时，都可以根据logid找到所有的日志，如果把所有的日志都收集到日志中心，就可以按时间序将所有的请求过程打印出来。染色体系是一个系统工程，需要底层框架的支持。
2024-09-18 00:50:24
183
转载 浅谈创业早期技术实现
创业最开始的时候，是最难的时候，此时，从0到1，从无到有，做的是自己不曾做过的事情，所以，我们称之为创业。对于早期的技术而言，不要大而全，不用高精尖，先按需求实现，活下来再说。我们需要考虑的是哪些可以用云服务，哪些可以直接用现成的开源方案或技术，哪些需要自己开发；我们可以粗旷一些，要的是快速出活，让产品活下来。前期那么几杆枪，就技术而行，要用团队成员最熟悉的，要有人能全盘掌控所有的技术栈。
2024-09-18 00:42:18
86
转载 图解RocketMQ架构
因为所有的消息都存在CommitLog中，如果要实现根据 key 查询 消息的方法，就会变得非常困难，所以为了解决这种业务需求，有了IndexFile的存在。用于为生成的索引文件提供访问服务，通过消息 Key 值查询消息真正的实体内容。IndexFile 如何创建？以创建的时间戳命名。参数：phyOffset物理偏移量（也就是commitLogOffset）、keys。如何查询消息呢？
2024-09-18 00:29:22
49
转载 MySQL锁相关总结｜悲观锁、乐观锁、读锁、写锁、表锁、行锁、页面锁、间隙锁、临键锁
总结MySQL 的锁可以分成三类：总体、类型、粒度。总体上分成两种：乐观锁和悲观锁类型上也是两种：读锁和写锁锁的粒度上可以分成五种：表锁，行锁，页面锁，间隙锁，临键锁下面我们就来详细讲一下这些锁。
2024-09-18 00:25:30
82
转载 拒绝一直写CRUD！！！使用回调机制Callback和函数式编程码出优雅结构化代码
回调（Callback）是一种编程模式，其中一个函数（或方法）在执行完成后通过调用另一个函数（或方法）来传递执行结果，或在特定事件发生时调用。这种模式常用于异步操作、事件驱动编程中，可以提升代码的可扩展性、灵活性和模块化。回调机制指的是将一个方法或函数作为参数传递给另一个方法，待特定事件或操作完成时调用这个方法，处理结果或执行后续操作。可以理解为一种“通知”机制，当一个任务完成时，调用回调函数来传递结果或执行后续逻辑回调可以分为同步回调和异步回调：异步回调。
2024-09-18 00:20:23
261
转载 后端架构师必备：提升系统性能的 6 大核心优化策略
【说明】全文约 18000 字，阅读需要约 40 分钟。是关于后端性能优化的系统性梳理，从缓存、批量处理、异步处理、数据压缩、并行化处理、避免不必要的请求等 6 个方面做了详细的表述。作为后台架构师，你是否经常面临系统响应缓慢、资源消耗过高、用户反馈不佳等问题？在复杂业务场景下，系统性能的瓶颈往往隐藏在不起眼的细节中，如何精准识别并高效解决这些问题，是每一个架构师必须掌握的核心技能。本文将为你揭示后台架构优化的六大核心方法——缓存、批量处理、异步处理、数据压缩、并行化处理和避免不必要的请求。
2024-09-18 00:07:35
1023
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人