<?xml version="1.0" encoding="utf-8" ?><rss version="2.0"><channel><title><![CDATA[曾子墨]]></title><description><![CDATA[欢迎光临]]></description><link>https://blog.csdn.net/aoxida</link><language>zh-cn</language><generator>https://blog.csdn.net/</generator><copyright><![CDATA[Copyright &copy; aoxida]]></copyright><item><title><![CDATA[redis--28.1--常见问题--Asynchronous AOF fsync is taking too long(disk is busy)]]></title><link>https://blog.csdn.net/aoxida/article/details/145377876</link><guid>https://blog.csdn.net/aoxida/article/details/145377876</guid><author>aoxida</author><pubDate>Mon, 27 Jan 2025 10:28:54 +0800</pubDate><description><![CDATA[如果开启了 appendfsync everysec 的fsync策略，并且no-appendfsync-on-rewrite参数为no，则redis在做AOF重写的时候，也会每秒将命令fsync到磁盘上，而此时Redis的写入量大而磁盘性能较差，fsync的等待就会严重；# 修改为一个小的值，例如32MB，达到这个数据量就fsync，让操作系统fsync这个动作更频繁一点，避免单次fsync太多数据，导致阻塞。Fsyncing在这个设置上取决于内核，甚至更少的磁盘压力和延迟尖峰的风险。]]></description><category></category></item><item><title><![CDATA[阿里：MySQL 单表数据最大不要超过多少行？为什么？]]></title><link>https://blog.csdn.net/aoxida/article/details/142321480</link><guid>https://blog.csdn.net/aoxida/article/details/142321480</guid><author>aoxida</author><pubDate>Wed, 18 Sep 2024 00:35:33 +0800</pubDate><description><![CDATA[于是顺着的record的页地址就到了6号数据页里，再判断id=5>4，所以肯定在右边的数据页里，于是加载105号数据页。B树将行数据都存在非叶子节点上，假设每个数据页还是16kb，掐头去尾每页剩15kb，并且一条数据表行数据还是占1kb，就算不考虑各种页指针的情况下，也只能放个15条数据。B+树叶子和非叶子结点的数据页都是16k，且数据结构一致，区别在于叶子节点放的是真实的行数据，而非叶子结点放的是主键和下一个页的地址。上面展示的是两层 的树，如果数据变多了，我们还可以再通过类似的方法，再往上构建一层。]]></description><category></category></item><item><title><![CDATA[【MySQL】MySQL分库分表详解[通俗易懂]]]></title><link>https://blog.csdn.net/aoxida/article/details/142320494</link><guid>https://blog.csdn.net/aoxida/article/details/142320494</guid><author>aoxida</author><pubDate>Tue, 17 Sep 2024 22:59:04 +0800</pubDate><description><![CDATA[在互联网还未崛起的时代,我们的传统应用都有这样一个特点：访问量、数据量都比较小，单库单表都完全可以支撑整个业务。随着互联网的发展和用户规模的迅速扩大,对系统的要求也越来越高。因此传统的MySQL单库单表架构的性能问题就暴露出来了。]]></description><category></category></item><item><title><![CDATA[Redisson Queue实现]]></title><link>https://blog.csdn.net/aoxida/article/details/140347738</link><guid>https://blog.csdn.net/aoxida/article/details/140347738</guid><author>aoxida</author><pubDate>Thu, 11 Jul 2024 11:45:43 +0800</pubDate><description><![CDATA[/ POLL_SIZE表示一次拉取多少条消息，不传取1条。RQueue是非阻塞消息队列。]]></description><category></category></item><item><title><![CDATA[高并发系统设计：MySQL存储海量数据的最后一招---分库分表]]></title><link>https://blog.csdn.net/aoxida/article/details/136149082</link><guid>https://blog.csdn.net/aoxida/article/details/136149082</guid><author>aoxida</author><pubDate>Sun, 18 Feb 2024 11:47:10 +0800</pubDate><description><![CDATA[另外，不建议在方案中考虑二次扩容的问题，也就是考虑未来的并发量，把这次分库分表设计的容量都填满了之后，数据如何再次分裂的问题。现在技术和业务变化这么快，等真正到了那个时候，业务早就变了，可能新的技术也出来了，之前设计的二次扩容方案大概率是用不上的，所以没必要为了这个而增加方案的复杂程度。类似于订单商品表这类订单的相关的子表，也是需要按照同样的方式归档到各自的历史表中，由于它们都是用订单 ID 作为外键来关联到订单主表的，随着订单主表中的订单一起归档就可以了。问题：解决海量数据的问题，能不能用分布式存储呢？]]></description><category></category></item><item><title><![CDATA[如何设计秒杀系统？]]></title><link>https://blog.csdn.net/aoxida/article/details/136147182</link><guid>https://blog.csdn.net/aoxida/article/details/136147182</guid><author>aoxida</author><pubDate>Sun, 18 Feb 2024 10:44:40 +0800</pubDate><description><![CDATA[https://download.csdn.net/download/aoxida/88843363]]></description><category></category></item><item><title><![CDATA[Error:Kotlin: Module was compiled with an incompatible version of Kotlin. The binary version of its]]></title><link>https://blog.csdn.net/aoxida/article/details/132875476</link><guid>https://blog.csdn.net/aoxida/article/details/132875476</guid><author>aoxida</author><pubDate>Thu, 14 Sep 2023 14:29:17 +0800</pubDate><description><![CDATA[项目编译过程中遇到Kotlin的编译问题，解决办法：Build菜单->Rebuild Project。]]></description><category></category></item><item><title><![CDATA[献给春天的演讲：扎根]]></title><link>https://blog.csdn.net/aoxida/article/details/129644841</link><guid>https://blog.csdn.net/aoxida/article/details/129644841</guid><author>aoxida</author><pubDate>Sat, 18 Mar 2023 23:10:29 +0800</pubDate><description><![CDATA[【#献给春天的演讲#：扎根】终究有一天，我们会变成一棵参天大树。

【原文】

我是张颂文，我是一名演员，今年春节，我在社交媒体上面收到最多的一个评论：恭喜你，张颂文！你的春天来了。很多朋友，大部分的对我的肯定都带一点点同情，大家都觉得，在没有人看见他的地方，他努力了二十年。

我从很小的时候就喜欢花花草草，我第一次种花应该是在我四岁那一年，我的隔壁邻居里，有一个叫卢伯伯的人，卢伯伯有个爱好，他在我们后山里会挖很多矮小的树根，然后回家种在盆里，没多久，这个树根就开始散发出枝叶，他种过很多形态各异的盆栽，我看]]></description><category></category></item><item><title><![CDATA[Redis删除机制]]></title><link>https://blog.csdn.net/aoxida/article/details/129058263</link><guid>https://blog.csdn.net/aoxida/article/details/129058263</guid><author>aoxida</author><pubDate>Thu, 16 Feb 2023 12:06:58 +0800</pubDate><description><![CDATA[Redis过期删除]]></description><category></category></item><item><title><![CDATA[Redisson 分布式锁]]></title><link>https://blog.csdn.net/aoxida/article/details/128126202</link><guid>https://blog.csdn.net/aoxida/article/details/128126202</guid><author>aoxida</author><pubDate>Thu, 01 Dec 2022 09:24:09 +0800</pubDate><description><![CDATA[Redisson]]></description><category></category></item><item><title><![CDATA[MAC忽略git提交DS_Store文件]]></title><link>https://blog.csdn.net/aoxida/article/details/127416301</link><guid>https://blog.csdn.net/aoxida/article/details/127416301</guid><author>aoxida</author><pubDate>Wed, 19 Oct 2022 21:28:35 +0800</pubDate><description><![CDATA[MAC电脑忽略DS_Store]]></description><category></category></item><item><title><![CDATA[聊聊高并发下库存加减那些事儿——“如何实现异步扣减库存”]]></title><link>https://blog.csdn.net/aoxida/article/details/123880033</link><guid>https://blog.csdn.net/aoxida/article/details/123880033</guid><author>aoxida</author><pubDate>Thu, 31 Mar 2022 18:27:35 +0800</pubDate><description><![CDATA[　　一般在日常开发中经常会遇到打折促销，秒杀活动，就如拼多多最近的4999抢券买爱疯11促销活动，毕竟谁的钱也不是大风刮来的，有秒杀有促销必定带来大量用户，而这类活动往往支撑着公司重要营销策略，所以保证系统在高并发下不出异常非常关键，这其中棘手的便是如何在高并发下高效的处理库存数据。今天就来聊聊高并发下库存加减那些事儿。



　　首先我们要明确重要的一点是减库存是需要顺序的，而需要顺序就意味着不能有并发加减库存的操作，为了实现顺序，一般做法都是将多线程强行变为单线程实现同步操作或者所说的顺序，将多线...]]></description><category></category></item><item><title><![CDATA[MySQL LIMIT 理解]]></title><link>https://blog.csdn.net/aoxida/article/details/123817614</link><guid>https://blog.csdn.net/aoxida/article/details/123817614</guid><author>aoxida</author><pubDate>Tue, 29 Mar 2022 11:57:05 +0800</pubDate><description><![CDATA[MYSQL LIMIT]]></description><category></category></item><item><title><![CDATA[JDK8 stream常用的几个方法]]></title><link>https://blog.csdn.net/aoxida/article/details/121659921</link><guid>https://blog.csdn.net/aoxida/article/details/121659921</guid><author>aoxida</author><pubDate>Tue, 07 Dec 2021 16:58:24 +0800</pubDate><description><![CDATA[map
可以使用map方法把对象中的某个属性取出后，重新（加工）组成新的列表。


        Student s1 = new Student("AB-1", 10);
        Student s2 = new Student("CD-2", 12);
        Student s3 = new Student("EF-3", 15);

        List&lt;Student&gt; list = new ArrayList&lt;&gt;();
        list.a.]]></description><category></category></item><item><title><![CDATA[MySQL的聚簇索引和非聚簇索引]]></title><link>https://blog.csdn.net/aoxida/article/details/121701777</link><guid>https://blog.csdn.net/aoxida/article/details/121701777</guid><author>aoxida</author><pubDate>Fri, 03 Dec 2021 16:41:02 +0800</pubDate><description><![CDATA[MySQL常见的存储引擎有InnoDB和MyISAM。

InnoDB中，（一级索引）数据和索引是存储在同一个文件（数据文件.idb），所以InnoDB主键索引结构中，既存储了数据还存储了主键值，就是聚簇索引。一般聚簇索引、一级索引、主键索引可以理解为一个东西。
聚簇索引的叶子节点即是数据节点，可直接关联到行数据。
每张表都有且仅有一个聚簇索引，会按照主键、唯一索引、生成rowid的顺序，采纳当做聚簇索引。聚簇索引是B+树结构，数据都是有序存储...]]></description><category></category></item><item><title><![CDATA[面试官又整新活，居然问我for循环用i++和++i哪个效率高？]]></title><link>https://blog.csdn.net/aoxida/article/details/121533069</link><guid>https://blog.csdn.net/aoxida/article/details/121533069</guid><author>aoxida</author><pubDate>Thu, 25 Nov 2021 11:00:49 +0800</pubDate><description><![CDATA[前几天，一个小伙伴告诉我，他在面试的时候被面试官问了这么一个问题：


在for循环中，到底应该用 i++ 还是 ++i ？


听到这，我感觉这面试官确实有点不按套路出牌了，放着好好的八股文不问，净整些幺蛾子的东西。在临走的时候，小伙伴问面试官这道题的答案是什么，面试官没有明确告诉答案，只是说让从程序执行的效率角度自己思考一下。

好吧，既然这个问题被抛了出来，那我们就见招拆招，也给以后面试的小伙伴们排一下坑。

思路

前面提到，这个搞事情的面试官说要从执行效率的角度思考，那我们就抛开语义上的区别，从运]]></description><category></category></item><item><title><![CDATA[SQL优化方法及实例]]></title><link>https://blog.csdn.net/aoxida/article/details/119573686</link><guid>https://blog.csdn.net/aoxida/article/details/119573686</guid><author>aoxida</author><pubDate>Tue, 10 Aug 2021 16:47:31 +0800</pubDate><description><![CDATA[很多朋友在做数据分析时，分析两分钟，跑数两小时？

在使用SQL过程中不仅要关注数据结果，同样要注意SQL语句的执行效率。

本文涉及三部分，篇幅较长，建议收藏后翻看：


	SQL介绍
	
	
	SQL优化方法
	
	
	SQL优化实例
	
1、MySQL的基本架构

1）MySQL的基础架构图





左边的client可以看成是客户端，客户端有很多，像我们经常你使用的CMD黑窗口，像我们经常用于学习的WorkBench，像企业经常使用的Navicat工具，它们都是一个客户端。右边的这一大堆都可以看成]]></description><category></category></item><item><title><![CDATA[Redis缓存穿透，缓存击穿，缓存雪崩]]></title><link>https://blog.csdn.net/aoxida/article/details/118803642</link><guid>https://blog.csdn.net/aoxida/article/details/118803642</guid><author>aoxida</author><pubDate>Fri, 16 Jul 2021 16:35:39 +0800</pubDate><description><![CDATA[缓存穿透
key对应的缓存不存在，此时程序会触发读取数据源，如果并发量较大，可能会持续亚到DB。

解决方案：如果发现数据库不存在记录，可以把空结果缓存到Redis，这样就减少了DB的压力。

缓存击穿
    key对应的缓存已过期，此时如果大量并发请求，系统发现缓存过期，会重新从DB中加载数据到Redis，此时可能会瞬间把DB压垮。（感觉这个挺极端的场景????）

解决方案：

方案1：从DB中加载缓存的时候，使用分布式锁，只允许一个线程加载缓存；

    ...]]></description><category></category></item><item><title><![CDATA[Long包装类的比较]]></title><link>https://blog.csdn.net/aoxida/article/details/118493891</link><guid>https://blog.csdn.net/aoxida/article/details/118493891</guid><author>aoxida</author><pubDate>Mon, 05 Jul 2021 17:01:57 +0800</pubDate><description><![CDATA[要比较Long类型的值的，不能直接用 == ，某些情况下会出问题：

Long类中，有一个内部类LongCache，对-128到127的数值做了缓存，这个范围内的使用==是可以返回正确的值，超过这个范围就不成立。


可以直接使用equals方法，因为Long重写了equals方法，如下


public boolean equals(Object obj) {
        if (obj instanceof Long) {
            return value == ((Long)ob.]]></description><category></category></item><item><title><![CDATA[雪花算法（SnowFlake）]]></title><link>https://blog.csdn.net/aoxida/article/details/118414307</link><guid>https://blog.csdn.net/aoxida/article/details/118414307</guid><author>aoxida</author><pubDate>Fri, 02 Jul 2021 14:57:28 +0800</pubDate><description><![CDATA[本文不介绍原理，只介绍优缺点。

据国家大气研究中心的查尔斯·奈特称，一般的雪花大约由10^19个水分子组成。在雪花形成过程中，会形成不同的结构分支，所以说大自然中不存在两片完全一样的雪花，每一片雪花都拥有自己漂亮独特的形状。雪花算法表示生成的id如雪花般独一无二。

优点
在Java中生成的id是long类型的有序整数，相较uuid作为数据库的主键，更易用于索引搜索和排序，对数据库（MySQL B-Tree）友好。
	所有id是根据时间递增的，无法根据其计算出业务量，避免被爬虫遍历数据。
...]]></description><category></category></item></channel></rss>