详解“日切”原理

news/2024/11/30 8:43:54/文章来源:https://www.cnblogs.com/IT-Evan/p/18559172

探索支付领域的奥秘,深入了解日切的复杂世界。在这篇文章将带我们穿越历史的长河,从早期的钱庄货币到现代银行体系,全面解析日切的演变、挑战和实现模式。

我想很多人都不陌生,但日切究竟是如何实现的,日切前后及过程中都发生了什么,需要做哪些事情;不同的年代、不同的机构情形下,日切的实现模式有何异同,本文将彻底聊清楚

所谓日切就是切换到下一个记账日期,这里要先搞清楚一个事情,日切就意味上一个交易日结束,下一个交易日开始,也就是日切伴随着日终,二者形影不离,那么聊日切就必须聊日终处理,我们把它当成一件事来看

为了深刻理解日切模式,我们先看下日切的发展史

 

一、日切简史

大家可能觉得,我现在就在做账务,对日切感知并不明显,所以,日切有什么好讲的,如果你这么想,那只因为一个原因

时代变了,方式也变了;要想深度理解一个事物,就要站在历史发展的视角看它,你感知不到,可能是因为,它以更高级和隐蔽的形式存在

1)从重到轻

支付发展程度越高,效率越高,成本越低,其中就包括日切的处理

早期的钱庄货币是金属的,做账是手工的,加上没有现代会计方法作为依据,那么账务登记和管理效率相对较低,造成两个交易日之间的日终处理工作相对繁琐,可以理解为非常重的“日切/日终处理”时期

同样银行也经历了多个时期,例如最早期的手工账时期,用算盘算账,纸质账簿做账务登记,那么日切过程势必要处理的事务相对较多,而且需要的人力成本较高,用时较长

1979年,国务院批准银行业可以引进外国计算机进行试点,1987年开始,工行、中行、建行开始引入IBM的大型机和业务应用系统,结束了手工记账的时代,开启了信息化进程‌,那么很多工作交给了计算机去做,这时候的日终处理效率相比手工账时代就高多了,但是日切和日终的事务依然耦合在一起,需要停止联机交易进行日切和日终处理

这个阶段,每年的12月31号,一年最后一天的日切/年终也就是银行年终决算最忙的一天,进行全年损益结转利润,因为银行的账目很多,现金账、日记账、柜员账、网点的账等等都需要实现平衡,一分钱都不能错;这就导致每次年终决算就像打仗一样,全行联动,为确保数据无缺失、准确,需要进行大量的检查;听说每圆满完成一次年终决算,是要庆祝甚至放鞭炮的

而现在的年终决算,相比之前要轻松容易多了!

现代银行体系一般都可以提供7*24交易服务,那么如何实现即可以实现“7*24小时不间断联机交易,又可以实现日切、日终处理的顺利进行,就是这个时期需要重点解决的问题,这个时期的日切可以认为是极轻的日切时代,即然轻,那对它的感知就弱了

这里要掰扯清楚一点,就是虽然现在大部分都实现了7*24小时联机交易,但银行依然需要进行日终维护,二者之间并不是冲突的关系,不是说,我7* 24小时了,就不休息了,不维护了;只不过是系统维护和7* 24小时可以实现并行

2)从繁到简

上面讲到了7*24小时不间断交易处理是当下的流行;那么怎么兼顾实时交易不间断,而日终处理又可以顺利进行呢,就成了这个阶段最重要的课题

其实二者重点产生纠缠的是在日切点附近的“实时交易和日终处理”,二者存在依赖关系,例如日终处理需要上日终的静态日末余额,而实时交易的余额是动态实时更新不停息的

那么,切断二者的纠缠而形成轻联系,建立让彼此单独运行的模式,就是突破口

而上一日的日末余额和上一日数据的完整性是日终处理依赖的关键,所以,实时交易要确保提供这两个保证即可

那么在模式设计上就出现了双余额模式或者双表模式

可以这么理解,将实时交易和日终处理进行隔离,实时交易做自己的7*24小时,而日终处理在另一个区域单独进行,不阻碍也不干扰实时交易的进行,实时交易只需要保证提供日终处理需要的内容;也就是所谓的

“实时联机交易+日终批量处理”双模式

那么这也就是所谓的“日切&日终”强纠缠的繁琐日切模式,到了二者实现隔离的简日切模式,也就意味着,如果交易不需要关注日终,那么日切将变得极其简单

当然对于支付机构、交易平台,这是很容易实现,因为属于弱账户模式,哪怕没有日切和日终的概念,也可以实现数据的自然切割,按照自然日进行处理即可;而对于银行要实现这一点相对复杂,因为存在客户存款计息、贷款计息的管理,对静态余额的强依赖,所以即需要维持动态余额的更新,又需要确保静态余额的生成和不变

 

二、日切概述

日切简单的说就是记账日期的切换,变更系统的记账时间;也就是人为的将时间轴根据设定的“日切时间点”切割成一个一个的区间,从前一个区间到下一个区间的过程就是切换的过程;这里的切换时间点就是“日切点”

所以,通过日切点将连续的时间进行了切割,同时也对数据进行了切割,形成了一个个的数据集,例如23:00作为日切点,那么{T:23:00,T+1:23:00}就构成了一个数据集合区间

1)为什么要有“日切”

虽然自然时间是连续的,但是很多实务需要按周期进行或者以周期为单位进行管理

例如饭馆到了晚上21:00要打烊,然后盘点当天的账目、打扫卫生、为下一个营业日准备,这里的21:00其实就是日切点,日切后进行日终处理

同样银行也要上下班,下班后柜面业务收取的现金等线下业务需要进行盘点、入库,而核心系统的线上业务等也要进行一系列的日终处理,例如生成日末余额、生成总账、账目核算、计息等等,那么需要“日切点”作为两个周期的分割点

特别在手工账年代,日切及日终处理工作量尤其明显,只不过随着科技的发展、电子化的普及的数字化时代,这个过程全部交给电脑了,我们的感知变弱了

这里要清楚一点,日切完成不一定意味着立刻进入了下一个交易日,例如日切完成了,但是下一个周期的交易要等待次日9:00才开始,那时间上,日切点23:00到次日9:00这个区间算是“日终处理+休息时间+营业准备”时间,不营业,但有事做

虽然现在的交易大部分都是7*24小时不间断运转,但是日切后还是会涉及一些日终的处理,例如清算文件的生成、结算数据的生成与下发等,日终与与日间的实时交易处理明显不同,存在明显的周期性和集中性,需要以“日切点”作为日终实务处理的开始信号

这里也涉及到数据的切割问题,例如一个交易日的数据做为一个信息单元,我们的利息按日计算,众多系统之间、各个机构之间的数据都需要按照相同的切割规则完成,这样才能实现按周期的核算,例如渠道的清算文件以日为区间进行提供,那么这个区间的起始点,就是两个连续的“日切点”

所以,需要“日切”这样一个动作,执行日期的切换、实现数据分割、作为日终处理的标志,起到调度的作用

2)日切时间选择

日切时间在时间点选择上,往往选择没在夜间交易低估时段进行,因为日切前后需要进行一系列的事务处理,避免影响正常业务;例如有些银行选择23:00作为日切点;那么23:00以后的交易将划归到下一个交易日

3)日切要干嘛

从技术操作上,日切只是将记账日期进行变更,但是日切前后及日切过程中需要执行一系列的事务,还要协调众多系统之间的配合

例如全体系切换记账时间,采用最新的记账时间;进行多系统间数据的核对,保证每个系统都完成的数据的登记,进行账务的入账、总账的生成等

4)不同场景做的事不同

普通交易平台、支付机构、银行业务、清算、央行等在日切点关注重点和实现上存在差异

银行因为涉及到大量的账户,所以银行日切要重点关注账务处理的完整性和准确性以及日终处理;另外就是按日计息等工作,又需要重点关注日终余额或者日均余额进行计息,那么每日的日终静态余额显得很重要;同时银行又因为涉及到柜面、ATM等线下业务,监管申报和合规性检查等等,所以,银行的日切处理相对复杂,要做的工作较多

清算机构因为主要是做信息转接,所以清算机构日切的重点在交易数据的清分、汇总与清算处理上,没有那么重的账户处理业务,甚至清算机构会存在场切,每小时一个场次,场次之间也存在固定时间点的切换

央行的日切或者日终要确保清算场次内所有机构都可以完成清算,例如头寸不足的要排队撮合、没钱的可以拆解或者贷款,那么央行各系统日切保证清算完成避免出现系统性金融风险,当然清算文件的生成和下发也是重点之一

而支付机构或者交易平台相比金融机构,在日切需求上就没有那么明确的诉求了,核心目的就是确保完成对商户的记账和按周期准确结算,这也就意味着数据切割是重点

除了不同机构之间存在差异,同类机构中不同的企业之间也会存在差异,一个纯线上交易的平台和一个涉及线下门店业务的企业在日终处理上会存在差异

所以,虽然日切在原理实现上有通用性,但是具体的具体的场景、企业内部,需要根据实际的业务选择进行设计

 

三、日切的挑战

大家这么想,如果日切执行过程中大家都停止工作,那事情就好办了,在这个期间没有交易,把所有要做的日终处理都做完,再开启下一个工作日的交易,那么日切其实就是一个日切的切换

但是,实际上的日切业务不止是时间的切换,存在一连串的挑战

1)7*24小时不间断交易的挑战

实际情况是,业务和系统是7*24小时不间断运行的,采用什么样的模式处理实时不间断交易和日终批处理之间的协同,是一大挑战

2)多系统作业的协同挑战

一个交易体系所涉及系统数量众多,其中包括交易系统、支付系统、清结算系统、账务系统、会计系统、财务系统等等

而日切不只是账务系统记账日切的切换,还需要各个系统执行相应的日切任务

这里最大的挑战就是调度问题,因为系统之间的日切和日终处理存在顺序和依赖关系;谁先谁后,什么时候开始,什么时候结束;大家怎么知道上游已经结束了轮到自己了

例如,交易系统没有完成日期,没有确保所有上日交易都推送至账务核心,那账务核心执行日切就会出问题,例如记账数据不全,日终余额不准确,与上游核对存在差异等问题

3)数据切割的一致性

众多系统的存在,就意味着同一份数据会登记在很多系统中,同样就会存在多个时间属性,例如交易时间、清算时间、记账时间等等

那么在上下游核对时,确保彼此数据切割一致,否则依然会存在数据集合不同的问题,与外部渠道间也存在这个问题,例如银行日切点是23:00,而机构日切实00:00,那么二者同一个交易日期的数据集不同

除了数据切割时间不一致造成的差异之外,不同系统之间,即使日切点一致,也可能会存在差异,这里要了解一个现象:记账漂移

就是系统之间传递数据的时间差造成的时间整体向后推移,系统间在日切时间点附近造成了时间差现象

从图中可以看出来,即使实时记账,因为系统延迟等原因,会造成交易时间和记账时间存在△t的时间差异,这个差异就是记账漂移

如果远离日切点的日间交易,这种差异的影响并不明显,因为很少和核对数据间的具体时间的一致性;但是在日切点附近的交易就可能飘逸到下一个记账日期,也就是T日的交易,记账日期飘逸到了T+1,那么整个数据集合就形成了错配

当以日为单位进行数据核算时,你会发现,交易和账务层的数据并不一致;即所谓的时间差差异

你要不要通过一个模式来解决这个问题,怎么解决

所以,如何确保全局数据切割的一致,按那个时间切割,交易按交易时间切割,账务按记账时间切割,如果这样,这里就会天然存在时间差;这里的切割一致性保证涉及到交易、账务、会计、提供给客户的交易文件等,他们之间的一致性

 

四、日切原理

在介绍原理之前,大家要搞清楚并区别几个概念

日期的概念:交易日期、清算日期、记账日期、会计日期、对账日期、结算日期等,这里就详细说明了

余额的种类:动态实时账户余额、静态的账户日终余额、账户冻结余额、可用余额等

所谓动态即会随着交易的产生而不断变化,例如账户余额,这个是随着收入、支出的产生而动态变化的,这个余额用户需要实时看到,而且准确

所谓静态数据即数据一旦产生便不再变化,例如日终余额,一旦完成日切,日终余额生成,那么这个余额就不能再变了;像计息、总账核对等需要用到这个静态余额

4.1日切处理架构

下面看日切的全局实现,这里要明确几点

数据在系统之间的传递存在顺序性,交易不会绕过账务系统直接将数据提交给会计系统;其次,系统之间的“日切处理”存在顺序性和依赖关系;最后,每个系统的日切任务不同

1)统一调度模型

为了不让各个系统的日切处理各自为政,采用统一调度的模式,由日切子系统进行全局管理,通知各个系统执行日切,并监控日切进程和结果;按照预先设定的日切顺序和任务监管各个系统的日切业务

2)日切点与记账日期维护

日切子系统需要统一管理各类日切点,以及当前记账日期,作为公共参数,提供给各系统查询使用

同样,这里的日切点和记账日期可以按照业务线、产品、商户等多维度进行配置,以便实现更加灵活的日切业务和数据切割模式

例如,即使全业务都是0:00日切,但是像酒吧、ktv等夜场业务,可以选择在交易量最小的12:00进行日切,因为这类场所,夜间是交易量最大的时候

3)系统时段切割与运行状态管控

为了更好的日切任务,控制日终处理的进程,可以将全局时段进行切割,切割成时区段,在不同的时段执行对应的任务

例如银行系统日终处理被分割成三段:日切(Cut-Off)、日终批量(End-Of-Day)、 日初准备(Begin-Of-Day)

央行系统的系统控制更加复杂,阶段拆分如下图所示,因为涉及到多个支付系统,账务系统和会计系统;还要确保日终各个机构之间能够完成顺利清算

那么,可以将整个时间轴切割成如下阶段:正常交易、日切、日终处理、交易准备等

并将各阶段规划出系统状态,维护在日切子系统中进行统一控制

4.2动静拆分和隔离

前面我们介绍了在24小时交易中,日切点的实时和批处理的冲突性,那么

能不能实现7*24小时连续交易的前提,是在日切期间和日终处理阶段能不能进行交易

所以,我们将实时的动态区,与日终的的静态区进行隔离,中间依靠隔离区通过“日切处理”建立起联系,这样就可以确保面向客户的7*24小时联机交易不间断,同时对内的日终处理又可以并行进行

那么,在日切阶段,如何处理此时的交易账务处理就成了关键

4.3日切账务处理模型

上述日切过程会产生两个数据,一个是动态账户余额数据,一个是静态日终余额数据

而动态余额和静态余额都是账户的属性,动态账户余额受交易启动实时变化,而静态日终余额受日终批处理生成;所以二者之间都依赖“账户”;同时日终余额又依赖动态的账户余额

这也就意味着,对同一个账户在日切期间会同时受到实时交易和日终处理的影响,可能会被两个事务同时更新;那么要确保这种并发更新不会造成问题,需要一个处理机制,例如账户双余额法、影子账户并行法、应入账日期标记法等

1)账务双余额法

这里要重点明确4个时间

交易时间:交易系统交易成功的时间,是交易系统的登记时间

记账时间:账务系统账务登记的时间,是交易数据推送至账务系统,按账务规则登记为凭证的时间

最后动账日期:账务系统一个账户最后更新的记账日期是什么时间,通过这个时间可以判断出,当前账户的入账情况,例如当前记账日期是10号,但是账户的最后动账日期是3号,那就意味着,4-10号之间没有进行过记账

当前记账日期:即日切子系统维护的当前的记账日期,这个日期所有系统是统一的,都遵循日切子系统的配置

搞清楚两个余额

账户当前余额:即当前这一个时刻,账户的余额,这是一个动态实时更新的余额,发生记账,这个余额就会实时变化;所以说这个余额由交易驱动实时更新

账户上日终余额:这个是上一日最后一笔交易记账完成后的账户余额,这个余额一旦生成,原则上不再发生变化,即是一个静态的余额;所以这个余额由日切驱动,在哪一个完成更新

这样,我们将账户设置3个参数,最后动账日期、上日终余额、当前余额他们之前存在如下关系

那么这里要做一个模式的选择,就是如何进行上日终余额的更新,因为当前余额的更新就是动账才更新,而日终余额的更新方式有多种

动账时更新上日终余额

即当账务有新的入账时,根据“最后动账日期和当前记账日期”来判断余额更新

如果“最后动账日=当前记账日”,即当前入账是当天的入账,只需要更新当前账户余额即可:Balance7=Balance6+本笔发生额;如下图所示

如果“最后动账日≠当前记账日”,即当前入账是新一天的入账,则需要更新上日终余额和当前账户余额:上日终余额更新为当前的账户余额Balance6;并再将当前余额更新为:Balance7=Balance6+本笔发生额;并将最后动账日更新为新的记账日期;如下图所示

这种更新模式下,因为没有动账的情况下上日终余额是不会更新的,所以日终余额的查询服务也要进行最后动账日和当前记账日期的查询

“最后动账日=当前记账日”:则直接取上日终余额字段的值即可

“最后动账日≠当前记账日”:说明已经完成日切了,但是新的记账日还没有入账,那么账户登记的上日终余额已经不是昨日了,而是更久之前的;此时应该取当前的账户余额作为“上日终余额”

日切时更新上日终余额

动账时更新上日终余额会造成“上日终余额”的不准确;所以可以执行日切时更新上日终,不管有没有动账发生,每次发生日期都进行上日终余额的更新,而且同时更新最后动账日期,这样每次取上日终余额,直接取即可

因为在日终处理过程中,联机交易也在进行,因为日终处理需要一定的时间,所以,为了确保联机交易正常对账务的更新,那么依然保持“动账更新余额的模式”

这就意味着,有可能出现联机交易和日终处理同时更新账户余额,那么为了解决这一问题,就需要进行账户余额的加锁;谁先更新,谁执行,另一方等待;直到锁解除了,等待的一方再执行余额更新

2)影子账户并行法

双账户方看起来逻辑简单,但是表结构比较复杂,而且按日更新余额模式下,可能存在日终处理和实时处理的账户余额更新冲突,会形成一个排队期,这样就会在日切点造成一定的账务延迟

那么为了确保联机交易和批量处理完全并行处理,而且不冲突,可以采用双账户法,即为每个分户设置一个影子临时账户,来处理日切和日终处理的冲突期的联机交易的实时记账

当系统运行状态进入日切和日终阶段时,临时影子账户开始运行,联机交易记账实时记账不再更新主账户,而是登记在这个临时账户中

正常记账期:主账户正常记账

双账户记账期:日终操作主账户,更新上日终余额,当前账户余额保持静止,此时期“当前账户余额=上日终账户余额”

该阶段需要注意一点,就是对外的账务服务,例如用户看到的“当前账户余额=主账户当前账户余额+临时账户发生额”

调账期:在这个时期,日间交易开始更新主账户,同时临时账户的临时登记交易也要调账到主账户,其实临时账户的调账跟联机交易更新主账户没有区别;调账完成以后,清空临时账户

3)应入账日期标记法

前面我们提出了一个记账漂移的现象,会造成系统间数据切割的不一致

可以通过上游系统标记该笔交易的“应入账日期”,来规避记账的漂移,例如在日切运行状态期间的记账,交易系统先执行了日切,那么最后5分钟的交易标记上“应入账时间”,这样,账务系统对于打上了应入账时间的交易执行记账时间修复机制,将其记账时间特殊处理标记为上一个记账日,来规避时间差问题

4)自然日切,不做特殊处理

当然对于像一些支付机构,交易平台,因为不涉及到计息、罚息、贷款预期等的业务处理,那么对日终余额没有过多依赖,像有的机构就不存在上日终余额这个数据,那么可以选择不设置日切机制;按照自然日自然日切即可

以上就是针对日切解决方案的一些常见思路和解法

 

五、日切案例

日切作为一个业务周期切换关键点,围绕日切这个时间点,也会发生一些有意思的事情

1)跨周期调账

及时做到万无一失,也会百密一疏,或者某些业务天然就存在一些固定时间调账的情况

例如,对上一个周期的补贴调入,漏账补入等等,都是要在一个新的记账日期去调入上一个记账日期的账,当然,这笔账也可以记入本期

2)上日终余额的用途很多

有些机构没有上日终余额,这个有时候会给他人造成困扰,例如如果商户需要做余额调节表,那么便无法获取到在机构账户的上日终余额,这无疑是一件很头疼的事情,总不能让商户自己用明细去计算吧

另外就是银行的利息计算一般按照上日终余额进行,很多业务都跟静态余额有关系,所以静态余额的生成和准确性对银行的存款业务、贷款业务至关重要

3)日切套利

早期很多银行的日切时间不同,有21:00的、有22:00的、有23:00的、有0:00的;在日切点会生成上日终余额

而银行计息又是根据上日终余额去计算,那么这里就有一个有意思的事情,将存款从一个机构的日切后取出,那么你是可以拿到上一天的利息的;在另一个机构的日切前存入,又可以拿到这个机构的一天的利息

所以,这是利用不同银行核心系统每日记账时点的时间差,短时间内在多家银行间转存,实现同一笔资金在同一日被多家银行确认为日终存款的行为

这里只是说明这种行为,是违法行为,大家请勿效仿

4)余额计息方法

了解一个计息方法,再去回看上面的日终余额,你会有一个更深刻的认识,为什么日终余额那么重要即根据存款账户的每日余额计算账户利息的一种方法,以上日终余额为计息基础

其中大写i是利息金额,Bi是第i日的存款余额即第i日的日终余额,r为年利率

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.hqwc.cn/news/840975.html

如若内容造成侵权/违法违规/事实不符,请联系编程知识网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

Windows Server 2025激活教程

Windows Server 如何把评估版升级改为正式版本并激活微软官方并不提供server系统的正式版本,只提供测试的评估版本,那么我们怎么修改为正式版本呢?1.确认版本开始————运行————CMD(管理员模式)cmd命令页面输入:winver 会弹出版本页面 查看具体为数据中心版还是标准…

《花100块做个摸鱼小网站! 》第十篇—响应式布局适配PC端和移动端

⭐️基础链接导航⭐️ 服务器 → ☁️ 阿里云活动地址 看样例 → 🐟 摸鱼小网站地址 学代码 → 💻 源码库地址一、前言 大家好呀,我是summo,小网站一直有个问题,就是PC端的样式和移动端的样式是两套,并且不能根据显示屏的大小进行动态化布局,如果PC端屏幕非常小就是这…

HCIA-09 VLAN原理与配置

主要介绍了虚拟局域网 (VLAN)的相关技术知识,包括:VLAN的作用,VLAN的标识及划分,VLAN的数据交互,VLAN的实际规划和应用,以及VLAN的相关基本配置。 通过VLAN技术,可以将物理的局域网划分成多个广播域,实现同一VLAN内的网络设备可以直接进行二层通信,不同VLAN内的设备不…

vxe-modal 实现窗口拖拽调整宽高

vxe-modal 实现窗口拖拽调整宽高 官网:https://vxeui.com<template><div><vxe-button content="点击弹出" @click="showPopup = true"></vxe-button><vxe-modal v-model="showPopup" title="标题1" :widt…

Tarjan学习笔记

强连通分量,缩点算法:Tarjan 代码及模板 强连通图:有向图,任意两点有路径 强连通分量:有向图,强连通子图数量 前置知识:dfs树(dfs序构成的树) 成分: 1.树边:dfs树上的边 (以下三种边是dfs树上没有但原图上有的边) 2.前向边:dfs树的祖先到儿子的边。 3.返祖边(后…

Mysql 数据库并发事物导致ABA问题排查解决

问题描述 一个更新计费参数接口,按钮连点导致数据未更新问题。 背景 接口内容逻辑,在一个事物内,先保存更新计费参数,再根据计费参数,重新计算费用,并刷新计费单,结算单,支付单等单据金额信息。按理来讲,这个接口是具备幂等性的,因为即便多次更新,也只是重新计算一遍…

工程化开发谷歌插件到底有爽

工程化开发谷歌插件到底有爽谷歌插件开发本质上就是写一些 html + js + css谷歌开发心得吧 manifest.json 文件{"manifest_version": 3,"name": "发布助手","version": "3.0","description": "前端资源监测&…

12-渗透测试

1、水平越权&垂直越权漏洞实验水平越权lucy用户登入成功后,将url的username参数由lucy改为kobe,即可查看到kobe的信息,实现水平越权垂直越权使用低权限用户pikachu访问添加用户页面,行使管理员admin用户的添加用户权限用户添加成功,实现垂直越权2、密码修改逻辑漏洞实…

vxe-modal 实现弹窗多窗口

官网:https://vxeui.com<template><div><p><vxe-button content="点击弹出" @click="openEvent"></vxe-button></p></div> </template><script> import { VxeUI } from vxe-pc-ui export default …

redis 流量增加过多问题排查解决

背景 Java项目,使用Redis集群。 现象 Redis集群,单台流量增加过多。 在redis服务器上:iftop -npP排查过程 发现流量上涨是同一台机器IP尾号3。到这台机器上查看。 top 命令查看进程idtop -H -p 1748 查看具体线程信息,可以看到,有三个线程执行100多小时,而且占用较多cpu…

RX23E-B系列微控制器是工业传感器设备的理想选择!R5F523E5B介绍,EFR32BG13P732F512GM48-D蓝牙/TH58NVG2S3HTAI0存储IC

RX23E-B系列微控制器是工业传感器设备的理想选择!R5F523E5B介绍,EFR32BG13P732F512GM48-D蓝牙/TH58NVG2S3HTAI0存储ICRX23E-B 系列微控制器具有内置模拟前端 (AFE),是工业传感器设备的理想选择。 与上一代的 RX23E-A 相比,RX23E-B 的24 位 Delta Sigma 模/数转换器在高速性…

100ASK_IMX6ULL-PRO 数码相框扩展项目:支持打开阅读 TXT 文件

背景说明 本篇内容基于百问网嵌入式Linux项目数码相框与文件浏览器和嵌入式Linux电子书阅读器 需求:在文件浏览器界面中支持双击打开TXT类型文件,进入新界面进行文本阅读和翻页控制。 实现思路说明 浏览器界面中响应双击操作,识别TXT类型文件成功后进入阅读器界面。可参考项…