首页
学习
活动
专区
圈层
工具
发布
    • 综合排序
    • 最热优先
    • 最新优先
    时间不限
  • 来自专栏软件设计

    RocketMQ源码分析之机制

    一、机制 1 时机 RocketMQ消息存储有了顺序写和内存映射的加持,写入性能得到了极大保证。 异步将消息写入到直接内存后就响应客户端,不会立刻,而是由异步线程每隔500ms执行FileChannel.forch()。 RocketMQ先将消息写入到堆外并立即返回响应生产端,然后异步将堆外的消息提交到页缓存,再异步。该机制最大优势是实现了批量化消息写入,缺点是消息会丢失。 图片 二、同步 同步采用组提交机制GroupCommitService,每次发送线程将消息写入到mmapedFile后,创建一个请求GroupCommitRequest,添加到requestsWrite 异步消息会先写入直接内存,再由异步线程每隔500ms将消息从直接内存写入到磁盘,性能好,而且页缓存压力小,但是丢失500ms的数据,不可靠。两种机制各有优缺点,需要根据业务场景来设置参数。

    1.5K70编辑于 2023-04-02
  • 来自专栏DBA随笔

    ​redo log的被动机制

    通常来讲,redo log的时机是在事务提交的commit阶段采取的,在此之前,redo log都存在于redo log buffer这块指定的内存区域中。 这里我们首先要明确两个概念和两个参数: write: fsync:持久化到磁盘 write()指的是MySQL从buffer pool中将内容写到系统的page cache中,并没有持久化到系统磁盘上 binlog fsync到磁盘上 取值N:每次提交事务都将binlog write到磁盘上,累计N个事务之后,执行fsync 但是,在某些特定场景下,redo log会在commit这个动作到来之前进行操作 ,例如下面的两种情况会让没有提交的事务的redo log写入磁盘: 1、redo log buffer占用的空间即将达到buffer pool的一般的时候,后台线程会主动,这个时候,由于事务没有提交 这个fsync的存在,再加上每秒一次的后台操作,innodb会认为redo log在commit的时候,就不需要fsync了,只write到文件系统的page cache就够了。

    4.9K30发布于 2020-06-19
  • 来自专栏大数据与实时计算

    【kafka】高吞吐源码分析-顺序写入与机制

    2.2.0的源码分析其机制顺序写入与机制的细节。 kafka本身提供强制机制来强制,下文将详细介绍 附加锁写入: Log -> LogSegment -> FileRecords // kafka.log.Log private def append 参数 kafka提供3个参数来优化机制 log.flush.interval.messages //多少条消息1次 log.flush.interval.ms //隔多长时间1次 log.flush.scheduler.interval.ms //周期性的。 log.flush.interval.messages log.flush.interval.messages即多少条消息1次,这个参数在Log类中使用。

    3.5K52发布于 2020-04-03
  • 来自专栏瓜农老梁

    RocketMQ存储--同步和异步【源码笔记】

    工作流程 3.异步线程类FlushRealTimeService工作流程 四、消息追加与线程类的交互 1.调用链 2.同步主要代码 3.异步主要代码 五、方式示意图 1.同步示意图 2.异步未开启堆外缓存示意图 3.异步开启堆外缓存示意图 六、文章总结 七、主要源码类清单 一、问题思考 1.同步是怎么工作的? 即相对偏移量,到什么位置了,下次从此处即可 2.flushedWhere 标记已经的物理偏移量,根据此位置可精确查找到文件中消息的存储位置。 #handleDiskFlush 2.同步主要代码 同步时构造请求,将请求提交给线程类GroupCommitService,service.putRequest(request),并获取盘结果 2.异步未开启堆外缓存示意图 ? 3.异步开启堆外缓存示意图 ?

    2.7K20发布于 2019-08-23
  • 来自专栏开源部署

    MySQL InnoDB 日志管理机制中的MTR和日志

    1.MTR(mini-transaction)  在MySQL的 InnoDB日志管理机制中,有一个很重要的概念就是MTR。 MTR是InnoDB存储擎中一个很重要的用来保证物理写的完整性和持久性的机制。 先看下MTR在MysQL架构中的位置。 MTR是上面的逻辑层与下面物理层的交互窗口,同时也是用来保证下层物理数据正确性、完整性及持久性的机制。 2.日志的触发条件 触发条件 描述 时间 线程默认每秒刷新一次。 ) 0:每次事务提交时,根本不会去日志缓冲区。 该模式下,MySQL会每秒执行一次 flush(到磁盘)操作。 注意事项 当设置为0,该模式速度最快,但不太安全,这种设置是最危险的。

    1K10编辑于 2022-08-17
  • 来自专栏idba

    针对 MySQLInnoDB 调优

    www.percona.com/blog/2020/05/14/tuning-mysql-innodb-flushing-for-a-write-intensive-workload/ 前言 这篇文章是讲述 InnoDB 策略系列文章的第三篇 MySQL 8.0.19 之前的版本 innodb_io_capacity 该参数的默认值是200,如果你阅读过我们之前写的文章, innodb_io_capacity 定义了 InnoDB 后台线程脏页时的 从上面的 MySQL 日志中可以看出来, 硬件的 IO 能力跟不上InnoDB 脏的速度,(理论上应该1000毫秒内完成的动作实际上花费4460毫秒将脏页刷新到磁盘,它接受脏页的数量远远大于它每秒能够处理脏页的能力 我们还花费大量时间阅读代码以了解 InnoDB 的运行机制。像往常一样,我们对评论持开放态度,但如果可能,请尝试通过引用代码或可重现的用例来支持任何反对我们观点的论点。

    2.5K31编辑于 2022-07-30
  • 来自专栏java 成神之路

    RocketMQ 同步实现原理

    (后台定时任务进行,每隔10毫秒批量。 10毫秒中如果有多个请求,则多个请求一块) service.putRequest(request); //等待请求结果(最长等待5秒钟,盘成功后马上可以获取结果 同步时使用 GroupCommitService 异步时使用 FlushRealTimeService 如果开启 isTransientStorePoolEnable 则同时也使用 CommitRealTimeService 策略。 CommitRealTimeService 策略和 FlushRealTimeService 策略是同时运行的 这里先介绍下同步策略 同步策略 class GroupCommitService

    1.5K10发布于 2019-01-03
  • 来自专栏架构师之路

    ,还是不,是一个问题 | 架构师之路重启

    数据库使用缓冲池(buffer pool)机制提升读写效率; 2. 数据库以数据页(page)为单位管理缓冲池; 3. 如果被读取的数据在缓冲池中,直接从缓冲池中读取数据; 4. 缓冲池中的数据不能实时回磁盘,毕竟事务还没有提交; 此例中,缓冲池中的数据被修改为2,磁盘上的数据仍是1(如上图)。 那么,问题来了,如果缓冲池满了,要将哪些数据回磁盘呢? 如果事务未提交,“脏”数据不会被回磁盘; 2. 如果事务已提交,数据会被回磁盘。 反之,如果将数据回磁盘,但此时事务T1还没有提交/回滚,事务T1的脏数据回磁盘,事务T1的ACID特性也会被破坏。 我们似乎陷入了一个两难的境地。如果是你,你会考虑用什么思路解决这个问题呢? 数据库使用缓冲池(buffer pool)机制提升读写效率; 2. 数据库以数据页(page)为单位管理缓冲池; 3. 数据库直接读写缓冲池中的数据; 4. 此情况,,还是不

    24310编辑于 2024-07-01
  • 来自专栏小赵的Java学习

    MySQL的机制

    可以通innodb_io_capacity参数来控制InnoDB的能力,这个值建议设置成磁盘的IOPS,通过fio工具可以测试出磁盘的IOPS,命令如下: fio -filename=$filename InnoDB的速度就通过脏页比例和redo log写盘速度来控制的. performance_schema.global_status where VARIABLE_NAME = 'Innodb_buffer_pool_pages_total'; select @a/@b; 连带机制 一旦一个查询请求需要在执行过程中刷掉一个脏页时,这个查询就可能要比平时慢了,MySQL中的一个机制可能会让查询更慢。 通过innodb_flush_neighbors可以控制这个行为,值为1的时候会有上述的连带机制,MySQL8.0以下默认为1。 ​

    99830编辑于 2022-12-02
  • 来自专栏青益云记

    「  etchdroid制作启动-手机制作启动  」

    有的时候电脑坏了,想要重装系统来解决,却无奈没有重装电脑的系统,所以本文介绍一款APP,可以让你在手机上刻录系统镜像在U盘上 材料准备: 1.EtchDroid(这款APP将在文末提供下载链接) 2. 系统镜像(自己准备去) 3.OTG线(请确认你的手机是否支持OTG) 4.U(存储卡和读卡器的组合也行) 准备 将U插进OTG线的一段,并且接入手机 该APP分为两个模块,第一个是刻录ISO格式的 ,适用于Windows和Linux,第二个是刻度苹果系统的(看自己要刻录那种) 点击进去后,选择你的U,然后选择文件刻录,然后会出现自动挂在后台刻录 -个人 挺便利的软件,经过测试刻录出来是可以正常使用的

    11K20编辑于 2023-01-03
  • 来自专栏Java开发者

    Apache RocketMQ 策略与复制策略

    由于磁盘速度大于网卡速度,那么的进度肯定可以跟上消息的写入速度。 同步(SYNC_FLUSH): ? 2.png 返回成功状态时,消息已经被写入磁盘。 消息写入内存 pagecache 后,立即通知线程,完成后,返回消息写成功的状态。 同步与异步的唯一区别是异步写完 pagecache 直接返回,而同步需要等待完成才返回, 同步流程如下: 写入 pagecache 后,线程等待,通知线程线程后,唤醒前端等待线程,可能是一批线程。 前端等待线程吐用户返回成功。 复制策略: 同步复制(SYNC_MASTER): master 和 slave 都写成功后返回成功状态。 推荐策略: 异步(ASYNC_FLUSH) + 同步复制(SYNC_MASTER)。

    1.5K60发布于 2019-04-11
  • 来自专栏shysh95

    MySQL字符串索引&脏页

    MySQL在更新数据的时候会写redo log并且更新内存以后就会返回,数据文件并不会立即更新,这就是所谓的WAL机制。 什么叫脏页? 内存数据页中的内容被写入磁盘数据页中的过程称为脏页。 什么时候会脏页? ,如果一次淘汰的脏页太多,会导致查询响应时间变长 MySQL空闲时,会进行脏页操作 MySQL正常关闭时,会进行脏页操作 InnoDB如何控制脏页的频率? into @b from global_status where VARIABLE_NAME = 'Innodb_buffer_pool_pages_total'; select @a/@b; 连坐机制 InnoDB在脏页的时候,如果该脏页旁边的页也是脏页,会同时把相邻的脏页刷掉。

    80910编辑于 2022-02-16
  • 来自专栏SH的全栈笔记

    MySQL 表数据多久一次

    表数据 我们这篇「短文」讨论的是【MySQL 表数据多久一次】,从这个标题中我们可以分裂成两个问题: 什么到磁盘 什么时候到磁盘 我们分开来讨论。 2. 和 InnoDB 的其他日志例如 Redo Log 一样,这些日志都是有自己的策略。 例如 Redo Log,其策略可以用下图来表示: 参数为0,Redo Log 会每隔一秒,写入并且入磁盘。 举个例子,Buffer Pool 中总共有 100 张页,脏页如果达到了 10 页就会启动后台线程,触发刷。 换句话说,默认情况,阈值是 10%,如果需要自定义,则最大值不能超过 90%。 4. 谁来负责 上个小节已经说过了,会启动线程来专门做这个事情,这个没有什么疑问。

    1K10编辑于 2022-08-17
  • 来自专栏运维经验分享

    【U机】小米路由器变砖如何100%机成功

    ”的三重保障机制来确保系统的稳定运行与数据的安全。 本期带来的get√新技能:U机—小米路由器变砖之后如何自救 本教程只针对出现下述情况无法正常启动的情况,才需要用到的U机恢复。 重要的事情说三遍:U机时会清空硬盘上的数据! 可以连接到路由器管理后台进行网页一键机恢复,如果恢复失败则需要用到U机。 对于小米路由器mini(R1C)和全新小米路由器硬盘版(R2D)来说,需要直接使用U机来恢复。 U机步骤: 1、准备一个系统格式为FAT或FAT32的U; 2、到小米路由器的官网miwifi.com下载用来进行机的ROM包; 重要的事情再说三遍:U机会清空硬盘上的数据! ROM包在进行U机时不会清除掉硬盘上的数据,但可能会因为硬盘的问题导致机失败。

    9.2K40发布于 2019-05-15
  • 来自专栏程序员的成长之路

    【原创】JVM 的类加载机制它!

    JVM 类加载机制分为五个部分:加载,验证,准备,解析,初始化。

    1K20发布于 2020-04-21
  • 来自专栏程序IT圈

    ​LeetCode题实战146:LRU 缓存机制

    今天和大家聊的问题叫做 LRU 缓存机制,我们先来看题面: https://leetcode-cn.com/problems/lru-cache/ Design a data structure that 题意 运用你所掌握的数据结构,设计和实现一个 LRU (最近最少使用) 缓存机制

    47240发布于 2021-01-19
  • 来自专栏golang算法架构leetcode技术php

    golangleetcode 经典(1) LRU缓存机制

    设计和实现一个 LRU (最近最少使用) 缓存机制。它应该支持以下操作:获取数据 get 和 写入数据 put 。

    58830编辑于 2022-08-02
  • 来自专栏爱可生开源社区

    第01问:MySQL 一次 insert 几次

    问题: MySQL 一次 insert 几次? 实验: 工具:pt-tools 1. 先检查各个参数 2. 开启 pt-tools 3. 在 MySQL 中,任意表插入一行 4. MySQL 对 redo log 进行了 3 次(fsync); 2. MySQL 对 binlog 进行了 1 次(fdatasync); 3. 对 redo log 和 binlog 的的方法是不同的。 结果: 可以看到本次试验进行了一次 insert,会对 redo log 进行 3 次,对 binlog 进行 1 次。 进行相同试验,会观察到不同结果:MySQL 有多个逻辑会引发刷,比如 InnoDB 主线程的脏等; 2. 每次 fsync,如果没有数据需要,不会对磁盘造成压力。 对于 3 次不必过分担心; 3. 以后我们会进行试验,分析到底是什么导致了

    66320发布于 2020-03-12
  • 来自专栏HUC思梦的java专栏

    RocketMQ消息丢失解决方案:同步+手动提交

    而且就算是os cache中的消息已经到了磁盘中,如果磁盘突然就坏了,消息是不是也就丢失了。 所以我们还要考虑Broker如何保证消息不丢失。 看过之前系列文章的小伙伴都知道,Broker是有两种机制的,同步和异步,详细内容可以回顾一下这篇文章:深入研究Broker是如何持久化的。 解决的方式就是把异步改为同步,具体操作就是修改一下broker的配置文件,将其中的flushDiskType配置设置为:SYNC_FLUSH,默认它的值是ASYNC_FLUSH,即异步。 调整为同步后,只要MQ告诉我们消息发送成功了,那么就说明消息已经在磁盘中了。 接下来就要解决磁盘坏了导致的消息丢失问题了。 而对于其他的没那么核心的场景,丢失一些数据问题也不大,就不应该采用这套方案了,或者说可以做一些简化,比如事务消息改成失败重试几次的机制策略改为异步

    1.7K21发布于 2020-10-30
  • 来自专栏维恩的派VNPIE

    vn.py的底层实现机制——实部分

    接下来详细的介绍一下这几种事件的区别作用以及整个以事件驱动为基础的实盘运行机制。 Event 1. EVENT_TICK,行情事件。 实交易概览 由于vn.py为事件驱动框架,我们就基于事件流来说明整个实的运行结构。如下图所示: ? (下图横屏浏览更佳,可点击放大,或点击文末“阅读原文”,进入‘维恩的派’论坛查看。

    2.8K31发布于 2018-07-26
领券