持久化在ActiveMQ Artemis中是如何工作的？
在ActiveMQ5.x中，当使用kahadb进行持久化时，所有文件都在一个数据库中管理。这会产生严重的后果。
我有数百个队列，每天看到数百万条消息。如果队列的使用者由于维护原因而暂时停止，队列将继续填充和清空，使用者被挂起的队列将看到消息累积。但在光盘上就不一样了。Kahadb确实会标记删除（消耗）的消息，但如果数据库中保留了更多的消息，则无法释放该位置。在挂起队列中积累的就是这种情况。磁盘空间很快就满了。要解决这个问题，您必须更改配置并使用Mkahadb。在这种情况下，每个队列有一个数据库，因此磁盘上只有挂起的队列占用空间。
我在考虑转投阿尔忒弥斯。但是持久性已经完全重新设计了。那么，当挂起一个使用者时，磁盘占用率会发生什么变化呢？
共有1个答案
这个问题很宽泛，但我想试试看...
默认情况下，ActiveMQ Artemis使用基于文件的日记。日记由一个文件池组成，这些文件池可以根据配置进行增长和收缩（请参见文档中的journal-min-files和journal-pool-files)。每个文件的大小也是可配置的（即通过journal-file-size)。
当代理启动时，将创建一个初始文件池，当消息存储和初始文件池填满时，将创建其他文件。当消息被使用时，池可以通过一个称为“压缩”的过程收缩，该过程也是可配置的（请参见文档中的journal-compact-min-files和journal-compact-percenty)。只要日记文件中的1条记录被认为是“活的”（例如，未使用的消息），那么整个日记文件就会保留下来。但是，您可以根据您的环境来调整它的影响（例如，通过降低Journal-File-Size，使压缩更加积极，等等）。明确地说，如果compaction运行，并且有一个日记文件只有1个“活动”记录，这意味着所有其他日记文件都是“满的”，您最多只能有1个这样的日记文件。
此外，您还可以配置max-disk-usage以在磁盘利用率达到一定程度时阻止生产者发送更多消息。
最终，如果消费者变得不活动（无论出于什么原因），那么消费者应该接收的消息将积累在队列中（可能在磁盘上）。如果首先要防止消息积累，可以对生成器实施流控制或阻塞。然而，即使它们积累了基于文件的日志，也应该能够根据需要增长和收缩。
-
我有一个事务性方法，在它的内部，一个实体被实例化，并使用persist方法插入到Hibernate上下文中。然后更改实体的某些属性（因此它将反映在数据库中）。如果对实体调用detach方法，然后更改实体的某些属性，会发生什么情况。当方法完成（和事务提交）时，Hibernate是否会插入实体并将属性更新到分离调用之前的点？ 例如：
-
我想保留一个文件，即使在卸载了我的应用程序在Android11。多亏了Android10和11关于存储的更新，我不能再这样做了。另外，我不想使用数据备份或远程服务器，它必须离线。有什么建议吗？
-
我刚开始接触微服务架构，我有几个关于数据持久性和数据库的问题。 所以我的理解是每个微服务都有自己的数据库（不一定，但通常）。但鉴于这种情况，请考虑一个包含用户、帖子和评论的常用社交媒体平台。将有两个微服务，一个用户的微服务和一个帖子的微服务。用户的数据库有一个用户表，帖子的数据库有一个帖子和评论表。 我的问题是关于帖子微服务，因为每个帖子和评论都有一个作者，所以通常我们会创建指向用户表的外键，但是
-
然而，有一个错误发生了，我确实找到了一个解决方案，但它是暂时的。 当我运行使用的Python脚本时，抛出以下错误消息： 失败 但是，如果我在VM运行时输入该命令()，它确实可以使事情正常工作！然而，这并不能解决我的问题，因为我需要它在启动时是ok的，而如果我重新进入VM，问题又回来了。 我的DockerFile：
-
Akka持久化使有状态的actor能留存其内部状态，以便在因JVM崩溃、监管者引起，或在集群中迁移导致的actor启动、重启时恢复它。Akka持久化背后的关键概念是持久化的只是一个actor的内部状态的的变化，而不是直接持久化其当前状态 （除了可选的快照）。这些更改永远只能被附加到存储，没什么是可变的，这使得高事务处理率和高效复制成为可能。有状态actor通过重放保存的变化来恢复，从而使它们可以重
-
我的应用程序有3个组件， 1） 一种面向用户的组件，接收请求并将其存储到数据库中。2）一个后端组件，从数据库中读取数据，进行处理并将其发送到外部系统。3） 存储用户输入的数据库 我如何测试流程是这样的：用户输入数据- 注意：我尝试使用ddl auto:update，但它不起作用。