qq_24692021的博客

spring-boot Arthas 定位问题

mycat 读写分离

spring boot单点登录

相信各位在日常工作中肯定会遇到应用程序莫名其妙崩溃的情况，比如常见的CPU100%，内存耗尽...当出现这些问题后我们就需要借助Linux命令来帮助我们定位发现问题，本文就给大家罗列一些Java后端线上问题排查的常用命令，建议直接收藏！内存瓶颈freefree是查看内存使用情况，包括物理内存、交换内存(swap)和内核缓冲区内存。free -h -s 3表示每隔三秒输出一次内存情况，命令如下[1014154@cc69dd4c5-4tdb5~]$free...

1、前言微服务的注册中心目前主流的有以下五种： Zookeeper Eureka Consul Nacos Kubernetes 那么实际开发中到底如何选择呢？这是一个值得深入研究的事情，别着急，今天陈某就带大家深入了解一下这五种注册中心以及如何选型的问题。这是《Spring Cloud 进阶》专栏第四篇文章，往期文章如下： 五十五张图告诉你微服务的灵魂摆渡者Nacos究竟有多强？ openFeign夺命连环9问，这谁受得了？

、前言消息队列中间件是分布式系统中重要的组件，主要解决应用耦合、异步消息、流量削锋等问题。它可以实现高性能、高可用、可伸缩和最终一致性架构，是大型分布式系统不可缺少的中间件。消息队列在电商系统、消息通讯、日志收集等应用中扮演着关键作用，以阿里为例，其研发的消息队列（RocketMQ）在历次天猫 “双十一” 活动中支撑了万亿级的数据洪峰，为大规模交易提供了有力保障。作为提升应用性能的重要手段，分布式消息队列技术在互联网领域得到了越来越广泛的关注 。本文将介绍四种常用的分布式消息队列开源软件：Kaf

前言Nacos是阿里巴巴开源的服务注册中心以及配置中心，致力于给开发者提供一款便捷、简单上手的开源框架。Nacos究竟有什么惊人的地方呢？看下图：从上图不难看出阿里巴巴的野心，一个Nacos干掉了Spring Cloud的三大组件，分别是注册中心Eureka、服务配置Config，服务总线Bus。本文目录结构如下图：为什么Nacos这么受欢迎？Nacos官方文档的介绍中有这么一句话，如下：Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。Nacos 是构建以“

在软件研发工程中，经常会遇到系统主键的唯一性问题，尤其是在现如今比较火热的微服务架构中。分布式ID 具备唯一性、高可用性、有序增长等特性，其生成策略也较为复杂。目前生成ID的方法多种多样，所适用的需求、场景及其性能也不尽相同。选择一种适合自己需求的解决方案是十分重要的。下面我们将对分布式系统下主键的生成策略总结一下，列举出其适用场景、优缺点等，为后续学习、工作提供参考。1. JDK自带的UUID程序设计语言开发工具包中都有生成主键的策略，以java语言的UUID为例（图1），它有着全球唯一的特性

前言日志是快速定位问题的好帮手，是撕逼和甩锅的利器！打印好日志非常重要。今天我们来聊聊日志打印的15个好建议~推荐下自己做的 Spring Boot 的实战项目：https://github.com/YunaiV/ruoyi-vue-pro1. 选择恰当的日志级别常见的日志级别有5种，分别是error、warn、info、debug、trace。日常开发中，我们需要选择恰当的日志级别，不要反手就是打印info哈~ error：错误日志，指比较严重的错误，对正常业务有影响..

数据库对象命名规范 数据库对象 数据库对象全局命名规范 数据库命名规范 表命名规范 字段命名规范 索引命名规范 视图命名规范 存储过程命名规范 函数命名规范 触发器命名规范 约束命名规范 用户命名规范 数据库对象设计规范 存储引擎的选择 字符集的选择 表设计规...

可以随便到网上查一查，各大互联网公司笔试面试特别喜欢考一道算法题，即 LRU缓存机制，又顺手查了一下LRU缓存机制最近有哪些企业喜欢考察，超级大热门！今天给大家分享一篇关于 Cache 的硬核的技术文，基本上关于Cache的所有知识点都可以在这篇文章里看到。关于 Cache 这方面内容图比较多，不想自己画了，所以图都来自《Computer Architecture : A Quantitative Approach》。这是一本体系架构方面的神书，推荐大家看一下。本文主要内容如

随着互联网信息技术的飞速发展，数据量不断增大，业务逻辑也日趋复杂，对系统的高并发访问、海量数据处理的场景也越来越多。如何用较低成本实现系统的高可用、易伸缩、可扩展等目标就显得越发重要。为了解决这一系列问题，系统架构也在不断演进。传统的集中式系统已经逐渐无法满足要求，分布式系统被使用在更多的场景中。分布式系统由独立的服务器通过网络松散耦合组成。在这个系统中每个服务器都是一台独立的主机，服务器之间通过内部网络连接。分布式系统有以下几个特点： 可扩展性：可通过横向水平扩展提高系统的性能和吞吐量。

前言这篇文章主要介绍一些目前主流的几种分布式解决方案以及阿里开源的一站式分布式解决方案Seata。文章有点长，耐心看完，看完你还不懂分布式事务，欢迎来捶我......文章目录如下：什么是分布式事务？分布式对应的是单体架构，互联网早起单体架构是非常流行的，好像是一个家族企业，大家在一个家里劳作，单体架构如下图：但是随着业务的复杂度提高，大家族人手不够，此时不得不招人，这样逐渐演变出了分布式服务，互相协作，每个服务负责不同的业务，架构如下图：分布式架构因此需要服务与服

当MySQL单表记录数过大时，增删改查性能都会急剧下降，可以参考以下步骤来优化：单表优化除非单表数据未来会一直不断上涨，否则不要一开始就考虑拆分，拆分会带来逻辑、部署、运维的各种复杂度，一般以整型值为主的表在千万级以下，字符串为主的表在五百万以下是没有太大问题的。而事实上很多时候MySQL单表的性能依然有不少优化空间，甚至能正常支撑千万级以上的数据量：字段 尽量使用TINYINT、SMALLINT、MEDIUM_INT作为整数类型而非INT，如果非负则加上UNSIGNED VAR

背景为了封禁某些爬虫或者恶意用户对服务器的请求，我们需要建立一个动态的 IP 黑名单。对于黑名单之内的 IP ，拒绝提供服务。架构实现 IP 黑名单的功能有很多途径：1、在操作系统层面，配置 iptables，拒绝指定 IP 的网络请求；2、在 Web Server 层面，通过 Nginx 自身的 deny 选项 或者 lua 插件 配置 IP 黑名单；3、在应用层面，在请求服务之前检查一遍客户端 IP 是否在黑名单。为了方便管理和共享，我们选择通过 Nginx+Lua+Redi

查询分离：表数据量大读写缓慢如何优化？ 01 讲中我们提到过，冷热分离解决方案的性价比高，但它并不是一个最优的方案，仍然存在诸多不足，比如：查询冷数据慢、业务无法再修改冷数据、冷数据多到一定程度系统依旧扛不住，我们如果想把这些问题一一解决掉，可以用另外一种解决方案——查询分离。（注意：查询分离与读写分离还是有区别的。）业务场景（架构经历二）我曾做过 SaaS 客服系统的...

冷热分离：表数据量大读写缓慢如何优化？业务场景我曾经做过供应链相关的架构优化，当时我们平台有一个订单功能，里面的主表有几千万的数据量，加上关联表，数据量达到上亿。这么庞大的数据量，让平台的查询订单变得格外迟缓，查询一次都要二三十秒，而且多点击几次就会出现宕机。比如业务员多次查询时，数据库的 CPU 会立马狂飙，服务器线程也降不下来。当时，我们尝试了优化表结构、业务代码、索引、SQL 语句等办法来提高响应速...