# at https://docs.hazelcast.com/
hazelcast:
# 集群的名称。单个集群的所有成员必须具有
# 配置相同的集群名称并连接到该集群的客户端
# 也必须使用它。
cluster-name: serverName
properties:
# 调整心跳和故障检测的属性
# 注意：这些通常通过system-properties配置，但也可以在properties块中设置
# 以下为示例值，请根据实际需求调整
hazelcast.heartbeat.interval.seconds: 5 # 心跳发送频率 (默认5秒)
hazelcast.heartbeat.timeout.seconds: 10 # 多少秒未收到心跳则认为可能离线 (默认10秒)
hazelcast.max.no.heartbeat.seconds: 60 # 多少秒未收到心跳则宣告成员死亡 (默认300秒)
hazelcast.heartbeat.fail.on.indefinite.freeze: true # 可以在更短的时间内宣布成员死亡
hazelcast.integrity.checker.enabled: true # Hazelcast 的完整性检查器,它可以在早期阶段让应用程序快速失败（"fail-fast"），而不是在数据操作中出现不可预测的错误或潜在的安全问题。
hazelcast.tpc.enabled: true # TPC (Thread-Per-Core) TPC 是一种 I/O 线程模型，旨在提高网络 I/O 的吞吐量和降低延迟，特别是在高并发场景下。如果您的应用有很高的网络 I/O 负载，启用 TPC 可能有助于提升性能。
network:
# Hazelcast 实例将监听的首选端口号。这
# 约定是使用 5701，这是此处和中的默认值
# 连接到 Hazelcast 的各种工具。
port:
# 确定成员是否自动尝试更高的端口 当首选数字被另一个进程占用时，数字。
auto-increment: true
#Hazelcast 端口绑定说明
#Hazelcast 将尝试绑定的端口数量。 默认的尝试次数是 100。
#基于此默认设置，如果你将端口值设置为 5701，那么随着集群成员的加入，Hazelcast 会尝试在 5701 到 5801 之间寻找可用的端口。
#你可以根据需要修改这个端口尝试次数，例如在单台机器上运行大量实例，或者你只想分配少量端口时。
port-count: 100
port: 5701
outbound-ports:
#连接其他节点时允许的端口范围。
#0 或 * 表示使用系统提供的（动态）端口。
- 5701
- 5702
- 5703
- 5704
- 5705
- 5706
- 5707
- 5708
- 5709
- 5710
# Hazelcast 集群自动发现机制
# Hazelcast 提供了多种技术来简化集群的形成，通过自动发现其他节点。
# 本配置章节列出了一些此类技术。
# Hazelcast 只会与使用相同发现机制的节点形成集群，因此请确保只启用其中一种机制。
join:
auto-detection:
enabled: true
# 通过 IP 组播发现节点
#这段配置描述了 Hazelcast 一种通过 IP 组播（IP multicast） 来自动发现集群节点的功能。
#这是最简单的技术，允许网络中的 Hazelcast 实例通过发送和监听组播消息来相互发现并组成集群。
#然而，需要注意的是，在云环境中，网络通常不允许使用组播。这意味着如果你在 AWS、Azure、GCP 等公共云上部署 Hazelcast，这种发现机制可能无法正常工作。在这种情况下，你需要考虑使用其他发现机制，例如 TCP/IP 发现或者专门为云环境设计的发现插件（如 AWS EC2 Discovery Plugin）。
multicast:
enabled: false
multicast-group: 224.2.2.3
multicast-port: 54327
# TCP/IP 发现（Discovery）机制
#这种技术不尝试任何自动发现。你直接列出所有要检查的候选 IP 地址。
#这意味着：
#你需要手动配置集群中所有潜在成员的 IP 地址或主机名。
#Hazelcast 会尝试连接到这些预设的 IP 地址来发现其他集群成员。
#它不依赖于多播或其他广播机制。
#这种方式适用于多播受限或被禁用的环境（例如许多云环境），或者当你需要对集群成员有明确控制时。
tcp-ip:
enabled: false
interface: 127.0.0.1
member-list:
- 127.0.0.1
# AWS 自动发现机制
# 指定成员是否使用 AWS API 来获取候选 IP 地址列表进行检查。
# 需要 AWS 的 "access-key"（访问密钥）和 "secret-key"（秘密密钥）来访问 AWS API。其余参数则作为过滤条件，用于缩小待检查的 IP 地址列表。
# 这意味着：
# Hazelcast 可以与 AWS API 集成，自动发现运行在 AWS 环境中的其他 Hazelcast 实例。
# 你需要提供有效的 AWS 凭证（访问密钥和秘密密钥）才能使此功能工作。
# 可以通过配置额外的参数（如标签、安全组等）来进一步筛选哪些 EC2 实例应该被视为集群成员。这对于在大型 AWS 环境中部署和管理集群非常有用。
aws:
enabled: false
# GCP 自动发现机制
# 指定成员是否使用 GCP API 来获取候选 IP 地址列表进行检查。
# 这意味着：
# Hazelcast 可以与 Google Cloud Platform (GCP) 的 API 集成，自动发现运行在 GCP 环境中的其他 Hazelcast 实例。
# 类似于 AWS 发现，GCP 发现机制允许 Hazelcast 成员动态地找到集群中的其他成员，而无需手动配置 IP 地址。
# 这通常需要适当的 GCP 身份验证和权限配置，以便 Hazelcast 能够调用 GCP API 来查询实例信息。
# 这种方式非常适合在 GCP 上部署大规模或动态的 Hazelcast 集群。
gcp:
enabled: false
# Azure 自动发现机制
# 指定成员是否使用 Azure REST API 来获取候选 IP 地址列表进行检查。
azure:
enabled: false
# Kubernetes 自动发现机制
# 指定成员是否使用 Kubernetes API 来获取候选 IP 地址列表进行检查。
# 这意味着：
# Hazelcast 可以与 Kubernetes API 集成，自动发现运行在 Kubernetes 集群中的其他 Hazelcast Pod。
# 这是在 Kubernetes 环境中部署 Hazelcast 集群时最推荐和最常用的发现机制。
# Hazelcast 会查询 Kubernetes API（例如通过服务、端点或标签选择器）来获取属于同一 Hazelcast 集群的 Pod 的 IP 地址。
# 这种方式使得 Hazelcast 集群能够很好地适应 Kubernetes 的动态特性，例如 Pod 的创建、销毁和重新调度。
# 使用此功能通常需要适当的 Kubernetes RBAC (Role-Based Access Control) 权限，以便 Hazelcast Pod 能够访问 Kubernetes API。
kubernetes:
enabled: false
eureka:
enabled: false
# Eureka 服务发现插件配置
# 指定 Eureka 发现 SPI 插件是否会向 Eureka 1 服务发现中心注册自身。
# 这是可选的配置项。默认值为 true。
self-registration: true
# Eureka 命名空间配置
# 定义一个 Eureka 命名空间，以避免与 eureka-client.properties 文件中其他服务注册客户端发生冲突。
# 这是可选的配置项。默认值为 hazelcast。
namespace: hazelcast
# 网络接口监听配置
# 指定要监听的网络接口。
# 如果将 "enabled"（启用）设置为 false，Hazelcast 将会监听所有可用的网络接口。
# 这意味着：
# 如果 enabled 为 true（通常是默认行为），你可以配置 Hazelcast 明确地只监听特定的网络接口（例如，指定一个 IP 地址或接口名称）。这在服务器有多个网卡，且你希望 Hazelcast 只绑定到其中一个时非常有用。
# 如果 enabled 为 false，Hazelcast 会尝试绑定到机器上所有可用的网络接口和 IP 地址，这意味着它可以在任何配置的网卡上接受连接。这通常是更宽松的配置，但在某些安全或网络隔离场景下可能不是最佳选择。
interfaces:
enabled: false
interfaces:
- 10.10.1.*
# SSL 配置（Hazelcast 企业版功能）
# 允许你使用 SSL 上下文工厂 (SSLContextFactory) 配置 SSL。
# 此功能仅在 Hazelcast 企业版中可用。
ssl:
enabled: false
# Socket 拦截器配置（Hazelcast 企业版功能）
# 此功能允许你添加自定义钩子（hooks）来加入集群并执行连接过程中的操作（例如，自定义认证协商协议等）。
# 此功能仅在 Hazelcast 企业版中可用。
# example:
# <socket-interceptor enabled="true">
# <class-name>
# com.hazelcast.examples.MySocketInterceptor
# </class-name>
# <properties>
# <property name="property1">value1</property>
# <property name="property2">value2</property>
# </properties>
# </socket-interceptor>
socket-interceptor:
enabled: false
# Socket 层通信加密配置（Hazelcast 企业版功能）
# 允许你加密所有 Hazelcast 成员之间完整的套接字（socket）级别通信。
# 此功能仅在 Hazelcast 企业版中可用。
# 它的配置包含了加密相关的属性，并且所有成员必须配置相同的加密配置。
# 默认情况下，此功能是禁用的。
symmetric-encryption:
enabled: false
# 加密算法示例
# DES/ECB/PKCS5Padding,
# PBEWithMD5AndDES,
# AES/CBC/PKCS5Padding,
# Blowfish,
# DESede
algorithm: PBEWithMD5AndDES
# salt value to use when generating the secret key
salt: thesalt
# pass phrase to use when generating the secret key
password: thepass
# 在生成密钥时使用的迭代次数
iteration-count: 19
failure-detector:
icmp:
enabled: false
# 分区组（Partition Grouping）配置选项
#当你启用分区组功能时，Hazelcast 为你提供了三种配置分区组的选择：
#主机感知（HOST_AWARE）：
#你可以自动根据节点的 IP 地址对节点进行分组。
#这样，共享同一个网络接口的节点将被分到同一组。
#在同一台主机（相同的 IP 地址或域名）上的所有成员都将属于单个分区组。
#自定义（CUSTOM）：
#你可以使用 Hazelcast 的接口匹配配置进行自定义分组。
#通过这种方式，你可以将不同且多个网络接口添加到同一个组中。
#每个成员一个组（PER_MEMBER）：
#你可以给每个成员指定它自己的独立组。
#每个成员都是一个独立的组，主分区（primary partition）和备份分区（backup partition）会随机分布（不会位于同一个物理成员上）。
partition-group:
enabled: false
# fail-on-max-backoff: true # 可选，当达到最大退避时间后是否立即失败
executor-service:
default:
# 执行器服务（Executor Service）线程数配置
# 每个成员（节点）的执行器服务所使用的执行线程数量。
# 这意味着：
# Hazelcast 提供了执行器服务，允许你将任务提交到集群中的成员上异步执行。
# 这个配置项决定了每个 Hazelcast 成员（即集群中的一个节点）会分配多少个线程来处理这些提交给执行器服务的任务。
# 增加这个数值可以提高并行处理任务的能力，但也可能增加资源消耗（CPU、内存）。
# 你需要根据你的应用负载和集群规模来调整这个线程数。
pool-size: 16
# 这里的意思是：队列的容量。如果设置为 0，则表示队列的最大容量为 Integer.MAX_VALUE (即 Java 中整型的最大值)。
# 简单来说：
# 0：队列将拥有一个非常大的、近似无限的容量，实际上只受限于系统内存。
# 任何正整数：队列的容量将被限制为你设置的具体数值。一旦队列中的元素数量达到这个值，新的元素将无法入队，直到有空间被释放。
# 这个配置项通常用于控制 Hazelcast 分布式队列（IQueue）的存储大小。
queue-capacity: 0
# 执行器服务统计信息收集配置
# 这个配置项用于指定是否收集并将此执行器服务（executor service）的统计信息存储在当前本地成员中。
# 简单来说：
# 如果启用（通常设置为 true），Hazelcast 会收集关于该执行器服务的运行数据，例如任务执行时间、队列大小、线程使用情况等。这些数据会保存在当前 Hazelcast 成员（节点）的内存中。
# 这些统计信息对于监控和分析你的应用性能非常有用，可以帮助你了解执行器服务的工作负载和潜在瓶颈。
# 如果禁用（设置为 false），则不会收集这些统计数据，这可以在一定程度上减少内存开销，但会失去对执行器服务运行状况的可见性。
statistics-enabled: true
durable-executor-service:
default:
capacity: 100
# 执行器服务的耐久性（Durability）配置
# 这个配置项指定了此执行器的耐久性。 耐久性代表了集群中针对任何给定分区拥有的任务所存在的副本数量。
# 如果此值设置为 0，则集群中任务只有一份副本。这意味着如果拥有该任务的分区发生故障（下线），该任务就会丢失。
# 默认值是 1，这意味着为每个任务创建一个
durability: 1
# 持久化执行器服务（Durable Executor Service）线程数配置
# 这段文档的中文翻译如下：
# 每个成员（节点）的持久化执行器服务所使用的执行线程数量。
# 这意味着：
# Hazelcast 提供了持久化执行器服务，它与普通的执行器服务类似，但增加了任务持久化和容错能力。即使成员重启，任务也可能被恢复并继续执行。
# 这个配置项决定了每个 Hazelcast 成员（即集群中的一个节点）会分配多少个线程来处理这些提交给持久化执行器服务的任务。
# 和普通执行器服务类似，增加这个数值可以提高并行处理任务的能力，但也可能增加资源消耗（CPU、内存）。
# 你需要根据你的应用负载、对任务持久性的需求以及集群规模来调整这个线程数。
pool-size: 16
# 执行器服务统计信息收集配置
# 它指定了是否收集此执行器服务的统计信息，并将其存储在当前的本地成员中。
# 简而言之：
# 如果启用此功能，Hazelcast 会收集关于该执行器服务的运行数据，比如任务执行时间、队列大小和线程使用情况。这些数据会保存在当前 Hazelcast 成员（即集群中的一个节点）的内存里。
# 这些统计信息对监控和分析应用程序性能非常有用，能帮你了解执行器服务的工作负载和潜在瓶颈。
# 如果禁用此功能，则不会收集这些统计数据，这能在一定程度上减少内存开销，但你也会失去对执行器服务运行状况的可见性。
statistics-enabled: true
scheduled-executor-service:
default:
# 调度器（Scheduler）容量配置
# 这个配置项指的是一个调度器在任何给定时间点，根据其容量策略所能拥有的最大任务数量。
# 一旦达到这个容量，新的任务将被拒绝。
# 在迁移过程中，此容量限制会被忽略，以防止任何不希望发生的数据丢失。
capacity: 100
# 持久化执行器（Durable Executor）的持久性配置
# 这个配置项用于设置持久化执行器的持久性（durability）级别。它代表了集群中每个由特定分区拥有的任务所拥有的副本数量。
# 如果将此值设置为 0：
# 表示集群中只有该任务的 1 个副本。
# 这意味着，一旦拥有该任务的分区所在的节点发生故障，这个任务就会丢失。
# 默认值为 1：
# 这意味着，每个任务都会创建一个主任务（ primary task）和一个备份任务（backup task）。
# 这样一来，即使主任务所在的分区或节点出现问题，备份任务也能确保任务的持久性和容错性，大大降低了任务丢失的风险。
durability: 1
# 执行器服务（Executor Service）中每个成员的线程数量
# 每个成员（节点）的执行器服务所使用的执行线程数量。
# 这意味着：
# Hazelcast 提供了一个执行器服务，它允许你将任务提交到集群中的各个成员（节点）上进行异步处理。
# 这个配置项决定了每个 Hazelcast 成员（即集群中的一个独立节点）会分配多少个线程来执行这些提交给执行器服务的任务。
# 增加这个数值可以提高并行处理任务的能力，从而可能加快任务的完成速度。
# 然而，也需要注意，增加线程数会消耗更多的系统资源（如 CPU 和内存）。因此，在配置时，你需要根据你的应用程序的负载特性和整个集群的规模来权衡并调整这个数值，以达到最佳的性能和资源利用率。
pool-size: 16
# 执行器服务统计信息收集配置
# 这个配置项的作用是决定是否收集此执行器服务（executor service）的统计信息，并将其存储在当前成员（节点）中。
statistics-enabled: true
security:
# 客户端执行器服务（Executor）权限配置
# 这个配置项控制着如何处理那些从客户端提交到执行器服务中，但没有明确权限映射的任务。
# true ：表示拒绝所有没有明确权限映射的任务。
# 这意味着，如果一个从客户端发来的任务没有被显式地赋予执行权限，它将被阻止运行。这是一种更严格、更安全的策略，确保只有经过授权的操作才能执行。
# false：表示允许所有没有明确权限映射的任务。
# 这意味着，即使一个从客户端发来的任务没有被显式地赋予执行权限，它也可以被执行。这是一种更宽松的策略，可能在开发或测试环境中方便，但在生产环境中可能会引入安全风险。
client-block-unmapped-actions: true
local-device:
# 设备分层存储配置
# 这个配置项是关于分层存储（tiered-store） 的，它允许你指定一个设备（device），供分层存储作为其磁盘层（disk-tier） 使用。
default-tiered-store-device:
base-dir: "tiered-store"
capacity:
unit: GIGABYTES
value: 256
block-size: 4096
read-io-thread-count: 4
write-io-thread-count: 4
map:
default:
# 存储 recordMap 的数据类型配置
# 这个配置项用于指定 Hazelcast 存储 recordMap 中数据时所采用的数据类型。它有以下几种可选值：
# BINARY (默认值)：
# 键（keys）和值（values）都将以二进制数据的形式存储。
# 这是默认且推荐的选项，因为它通常提供最佳的性能和内存效率，特别是在需要跨网络传输数据时。数据在存储前会被序列化成二进制格式。
# OBJECT：
# 值（values）将以它们的原始对象形式存储。
# 这意味着 Hazelcast 会直接存储 Java 对象，而不需要进行序列化/反序列化。这种模式可能在某些特定场景下有用，但通常会消耗更多内存，并且在集群间传输时仍需要进行对象序列化。
# NATIVE：
# 值（values）将存储在 JVM 的非堆（non-heap）区域。
# 这种方式允许 Hazelcast 将数据存储在 JVM 堆内存之外，有助于减少垃圾回收（GC）的压力，尤其是在处理大量数据时。这通常需要 Hazelcast 企业版或特定的配置，并且对内存管理有更精细的控制。
# 选择哪种数据类型取决于你的具体需求，包括性能、内存使用、垃圾回收行为以及是否使用 Hazelcast 企业版等。对于大多数场景，BINARY 是一个稳健的选择。
in-memory-format: BINARY
# Map 的元数据创建策略
# 这个配置项解释了 Hazelcast 如何为你的分布式映射（Map） 创建额外的数据信息，也就是元数据。Hazelcast 可以提前处理那些受支持类型的对象，从而生成关于它们的额外元数据。这些元数据的主要作用是加速查询和索引操作。
# 不过，请注意，创建元数据可能会降低写入（put）操作的吞吐量。
# 你可以选择以下两种策略：
# CREATE_ON_UPDATE (默认值)：
# 当支持类型的对象被创建或更新时，Hazelcast 会预先处理它们并生成相应的元数据。
# 这是推荐的默认设置，它能确保元数据始终是最新状态，从而保证查询和索引的高效性。
# OFF：
# 不创建任何元数据。
# 如果你选择此项，Hazelcast 将不会为加速查询和索引而预处理数据。这通常会提高写入操作的吞吐量，但作为代价，查询性能可能会受到影响。
# 简单来说：
# 如果你经常对 Hazelcast Map 中的数据进行查询或需要用到索引，那么保留默认的 CREATE_ON_UPDATE 策略是最好的选择，即使它可能稍微影响写入速度。但如果你的应用更侧重于高吞吐量的写入操作，并且查询需求不高，那么可以将策略设置为 OFF，以最大化写入性能。
metadata-policy: CREATE_ON_UPDATE
# 备份数量配置
# 这个配置项用于设置备份的数量。它决定了你的数据在集群中有多少份副本，以确保故障安全（fail-safety）。
backup-count: 1
# 异步备份数量配置
# 这个配置项用于设置异步备份的数量。
# 如果设置为 0，则表示没有异步备份。
async-backup-count: 0
# 映射（Map）条目存活时间（Time-to-Live）配置
# 这 个配置项是用来设定映射（map）中每个数据条目最长可以存留的秒数。
# 具体来说：
# 如果一个条目超过了 <time-to-live-seconds> 所设定的时间，并且在这段时间内没有被任何操作更新过，它就会被自动从映射中移除（逐出）。
# 你可以设置的整数值范围是 0 到 Integer.MAX_VALUE。
# 0：表示无限期存活，即该条目不会因为时间过期而被自动逐出。
# 默认值是 0。
time-to-live-seconds: 0
# 映射（Map）条目最大空闲时间（Max-Idle-Seconds）配置
# 这个配置项用于设定每个条目在映射（Map）中可以保持空闲状态的最大秒数。
# 如果一个条目空闲（即没有被任何操作“触摸”）的时间超过了 <max-idle-seconds> 所设定的时间，它将自动从映射中被逐出（evicted）。
# 一个条目被“触摸”的场景包括调用了 get、put 或 containsKey 方法。
# 你可以设置的整数值范围是 0 到 Integer.MAX_VALUE。
# 0：表示无限期空闲，即条目不会因为空闲时间过长而被自动逐出。
# 默认值是 0。
max-idle-seconds: 0
eviction:
# 逐出策略（Eviction Policy）配置
# 这个配置项定义了当映射（Map）达到其容量限制时，如何选择要逐出（移除）的条目。
# 以下是有效的逐出策略：
# NON E (无逐出)：
# 这是默认值。
# 表示不执行任何基于容量的逐出。如果映射达到其最大容量，并且没有其他策略（如 TTL 或 Max Idle）来清除条目，那么新的写入操作可能会被阻塞或失败，取决于具体的写入行为。
# LRU (Least Recently Used，最近最少使用)：
# 当需要逐出条目时，Hazelcast 会移除最近最少被访问或修改的条目。
# 这种策略基于“如果一个条目最近没有被使用，那么将来也不太可能被使用”的假设。
# LFU (Least Frequently Used，最不经常使用)：
# 当需要逐出条目时，Hazelcast 会移除访问频率最低的条目。
eviction-policy: NONE
max-size-policy: PER_NODE
# 映射（Map）的最大容量配置
# 这个配置项用于设定映射（Map）的最大尺寸（最大容量）。
# 当映射 达到这个最大尺寸时，Hazelcast 将根据之前定义的逐出策略（eviction policy） 来移除（evict）条目，以便为新数据腾出空间。
# 你可以设置的整数值范围是 0 到 Integer.MAX_VALUE。
# 0：表示最大尺寸为 Integer.MAX_VALUE，即实际上是无限容量（只受限于系统内存）。
# 默认值是 0。
size: 0
# While recovering from split-brain (network partitioning),
# map entries in the small cluster will merge into the bigger cluster
# based on the policy set here. When an entry merge into the
# cluster, there might an existing entry with the same key already.
# Values of these entries might be different for that same key.
# Which value should be set for the key? Conflict is resolved by
# the policy set here. Default policy is PutIfAbsentMapMergePolicy
#
# There are built-in merge policies such as
# com.hazelcast.spi.merge.PassThroughMergePolicy; entry will be overwritten if merging entry exists for the key.
# com.hazelcast.spi.merge.PutIfAbsentMergePolicy ; entry will be added if the merging entry doesn't exist in the cluster.
# com.hazelcast.spi.merge.HigherHitsMergePolicy ; entry with the higher hits wins.
# com.hazelcast.spi.merge.LatestUpdateMergePolicy ; entry with the latest update wins.
merge-policy:
batch-size: 100
class-name: com.hazelcast.spi.merge.PutIfAbsentMergePolicy
# Control caching of de-serialized values. Caching makes query evaluation faster, but it cost memory.
# Possible Values:
# NEVER: Never cache deserialized object
# INDEX-ONLY: Caches values only when they are inserted into an index.
# ALWAYS: Always cache deserialized values.
cache-deserialized-values: INDEX-ONLY
# Whether map level statistical information (total
# hits, memory-cost etc.) should be gathered and stored.
statistics-enabled: true
# Whether statistical information (hits, creation
# time, last access time etc.) should be gathered
# and stored. You have to enable this if you plan to
# implement a custom eviction policy, out-of-the-box
# eviction policies work regardless of this setting.
per-entry-stats-enabled: false
# Tiered Store configuration. By default, it is disabled.
tiered-store:
enabled: false
memory-tier:
# The amount of memory to be reserved for the memory-tier of the tiered-store instance of this map.
capacity:
unit: MEGABYTES
value: 256
# Whether disk-tier is enabled, and the name of the device to be used for the disk-tier
# of the tiered-store instance of this map.
disk-tier:
enabled: false
device-name: "default-tiered-store-device"
queue:
default:
# Maximum size of the queue. When a JVM's local queue size reaches the maximum,
# all put/offer operations will get blocked until the queue size
# of the JVM goes down below the maximum.
# Any integer between 0 and Integer.MAX_VALUE. 0 means
# Integer.MAX_VALUE. Default is 0.
max-size: 0
# Number of backups. If 1 is set as the backup-count for example,
# then all entries of the map will be copied to another JVM for
# fail-safety. 0 means no backup.
backup-count: 1
# Number of async backups. 0 means no backup.
async-backup-count: 0
# Used to purge unused or empty queues. If you define a value (time in
# seconds) for this element, then your queue will be destroyed if it
# stays empty or unused for that time.
empty-queue-ttl: -1
# While recovering from split-brain (network partitioning), data structure
# entries in the small cluster merge into the bigger cluster based on the
# policy set here. When an entry merges into the cluster, an entry with
# the same key (or value) might already exist in the cluster. The merge
# policy resolves these conflicts with different out-of-the-box or custom
# strategies. The out-of-the-box merge polices can be references by their
# simple class name. For custom merge policies you have to provide a
# fully qualified class name.
# The out-of-the-box policies are:
# DiscardMergePolicy: the entry from the smaller cluster will be
# discarded.
# HigherHitsMergePolicy: the entry with the higher number of hits wins.
# LatestAccessMergePolicy: the entry with the latest access wins.
# LatestUpdateMergePolicy: the entry with the latest update wins.
# PassThroughMergePolicy: the entry from the smaller cluster wins.
# PutIfAbsentMergePolicy: the entry from the smaller cluster wins if
# it doesn't exist in the cluster.
# The default policy is: PutIfAbsentMergePolicy
merge-policy:
batch-size: 100
class-name: com.hazelcast.spi.merge.PutIfAbsentMergePolicy
multimap:
default:
# Number of synchronous backups. For example, if 1 is set as the
# backup-count, then all entries of the list are copied to one other JVM
# for fail-safety. Valid numbers are 0 (no backup), 1, 2 ... 6.
backup-count: 1
# Type of the value collection. It can be SET or LIST.
value-collection-type: SET
# While recovering from split-brain (network partitioning), data structure
# entries in the small cluster merge into the bigger cluster based on the
# policy set here. When an entry merges into the cluster, an entry with
# the same key (or value) might already exist in the cluster. The merge
# policy resolves these conflicts with different out-of-the-box or custom
# strategies. The out-of-the-box merge polices can be references by their
# simple class name. For custom merge policies you have to provide a
# fully qualified class name.
# The out-of-the-box policies are:
# DiscardMergePolicy: the entry from the smaller cluster will be
# discarded.
# HigherHitsMergePolicy: the entry with the higher number of hits wins.
# LatestAccessMergePolicy: the entry with the latest access wins.
# LatestUpdateMergePolicy: the entry with the latest update wins.
# PassThroughMergePolicy: the entry from the smaller cluster wins.
# PutIfAbsentMergePolicy: the entry from the smaller cluster wins if
# it doesn't exist in the cluster.
# The default policy is: PutIfAbsentMergePolicy
merge-policy:
batch-size: 100
class-name: com.hazelcast.spi.merge.PutIfAbsentMergePolicy
replicatedmap:
default:
# Specifies in which format data will be stored in your replicated map.
# Available values are as follows:
# - BINARY: Data will be stored in serialized binary format. It is the
# default option.
# - OBJECT: Data will be stored in deserialized form.
in-memory-format: OBJECT
# Specifies whether the replicated map is available for reads before the
# initial replication is completed. Its default value is true. If false,
# no Exception will be thrown when the replicated map is not yet ready,
# but call is blocked until the initial replication is completed.
async-fillup: true
# When you enable it, you can retrieve replicated map entry statistics
# such as creation time, expiration time, number of hits, key, value, etc.
# Its default value is true.
statistics-enabled: true
merge-policy:
batch-size: 100
class-name: com.hazelcast.spi.merge.PutIfAbsentMergePolicy
list:
default:
# Number of synchronous backups. For example, if 1 is set as the
# backup-count, then all entries of the list are copied to one other JVM
# for fail-safety. Valid numbers are 0 (no backup), 1, 2 ... 6.
backup-count: 1
# While recovering from split-brain (network partitioning), data structure
# entries in the small cluster merge into the bigger cluster based on the
# policy set here. When an entry merges into the cluster, an entry with
# the same key (or value) might already exist in the cluster. The merge
# policy resolves these conflicts with different out-of-the-box or custom
# strategies. The out-of-the-box merge polices can be references by their
# simple class name. For custom merge policies you have to provide a
# fully qualified class name.
# The out-of-the-box policies are:
# DiscardMergePolicy: the entry from the smaller cluster will be
# discarded.
# HigherHitsMergePolicy: the entry with the higher number of hits wins.
# LatestAccessMergePolicy: the entry with the latest access wins.
# LatestUpdateMergePolicy: the entry with the latest update wins.
# PassThroughMergePolicy: the entry from the smaller cluster wins.
# PutIfAbsentMergePolicy: the entry from the smaller cluster wins if
# it doesn't exist in the cluster.
# The default policy is: PutIfAbsentMergePolicy
merge-policy:
batch-size: 100
class-name: com.hazelcast.spi.merge.PutIfAbsentMergePolicy
set:
default:
# Number of synchronous backups. Set is a non-partitioned data structure,
# so all entries of a Set reside in one partition. If it is set to 1,
# there will be 1 backup of that Set in another member in the cluster.
# When it is 2, 2 members will have the backup. Its default value is 1.
backup-count: 1
merge-policy:
batch-size: 100
class-name: com.hazelcast.spi.merge.PutIfAbsentMergePolicy
reliable-topic:
default:
# The batch size for reading from reliable topic. The ReliableTopic tries
# to read a batch of messages from the underlying ringbuffer. It will get
# at least one, but if there are more available, then it will try to get
# more to increase throughput.
read-batch-size: 10
# A policy to deal with an overloaded topic; so topic where there is no
# place to store new messages.
# The reliable topic uses a com.hazelcast.ringbuffer.Ringbuffer to store
# the messages. A ringbuffer doesn't track where readers are, so it has
# no concept of a slow consumers. This provides many advantages like high
# performance reads, but it also gives the ability to the reader to
# re-read the same message multiple times in case of an error. A
# ringbuffer has a limited, fixed capacity. A fast producer may overwrite
# old messages that are still being read by a slow consumer. To prevent
# this, we may configure a time-to-live on the ringbuffer (see
# com.hazelcast.config.RingbufferConfig#setTimeToLiveSeconds(int). Once
# the time-to-live is configured, the TopicOverloadPolicy controls how
# the publisher is going to deal with the situation that a ringbuffer is
# full and the oldest item in the ringbuffer is not old enough to get
# overwritten. Keep in mind that this retention period (time-to-live) can
# keep messages from being overwritten, even though all readers might have
# already completed reading. Its default value is BLOCK.
# Available values are as follows:
# - DISCARD_OLDEST: Using this policy, a message that has not expired
# can be overwritten. No matter the retention period set, the
# overwrite will just overwrite the item. This can be a problem for
# slow consumers because they were promised a certain time window
# to process messages. But it will benefit producers and fast
# consumers since they are able to continue. This policy sacrifices
# the slow producer in favor of fast producers/consumers.
# - DISCARD_NEWEST: Message that was to be published is discarded.
# - BLOCK: The caller will wait until there is space in the Ringbuffer.
# - ERROR: The publish call fails immediately
topic-overload-policy: BLOCK
# Specifies whether statistical information for the reliable topic
# is gathered and stored in this member.
statistics-enabled: true
ringbuffer:
default:
# The maximum number of items can be stored in the Ringbuffer.
capacity: 10000
# The number of synchronous backups. For example, if it is set to 1, then
# the Ringbuffer items are copied to one other member for fail-safety.
# Its default value is 1.
backup-count: 1
# The number of asynchronous backups. Its default value is 0.
async-backup-count: 0
# Specifies the time to live in seconds which is the maximum number of
# seconds for each item to stay in the ringbuffer before being removed.
# Entries that are older than time-to-live-seconds are removed from the
# ringbuffer on the next ringbuffer operation (read or write). Time to
# live can be disabled by setting time-to-live-seconds to 0. It means
# that items won't get removed because they expire. They may only be
# overwritten. When time-to-live-seconds is disabled and after the tail
# does a full loop in the ring, the ringbuffer size will always be equal
# to the capacity. The time-to-live-seconds can be any integer between 0
# and Integer#MAX_VALUE. 0 means infinite. The default is 0.
time-to-live-seconds: 0
# Sets the in-memory format. Setting the in-memory format controls the
# format of the stored item in the ringbuffer.
# The supported formats are:
# - OBJECT: the item is stored in deserialized format (a regular object)
# - BINARY (default): the item is stored in serialized format (a binary blob)
# The object in-memory format is useful when:
# - the object stored in object format has a smaller footprint than in
# binary format
# - if there are readers using a filter. Since for every filter
# invocation, the object needs to be available in object format.
in-memory-format: BINARY
# While recovering from split-brain (network partitioning), data structure
# entries in the small cluster merge into the bigger cluster based on the
# policy set here. When an entry merges into the cluster, an entry with
# the same key (or value) might already exist in the cluster. The merge
# policy resolves these conflicts with different out-of-the-box or custom
# strategies. The out-of-the-box merge polices can be references by their
# simple class name. For custom merge policies you have to provide a
# fully qualified class name.
# The out-of-the-box policies are:
# DiscardMergePolicy: the entry from the smaller cluster will be
# discarded.
# HigherHitsMergePolicy: the entry with the higher number of hits wins.
# LatestAccessMergePolicy: the entry with the latest access wins.
# LatestUpdateMergePolicy: the entry with the latest update wins.
# PassThroughMergePolicy: the entry from the smaller cluster wins.
# PutIfAbsentMergePolicy: the entry from the smaller cluster wins if
# it doesn't exist in the cluster.
# The default policy is: PutIfAbsentMergePolicy
merge-policy:
batch-size: 100
class-name: com.hazelcast.spi.merge.PutIfAbsentMergePolicy
flake-id-generator:
default:
# Sets how many IDs are pre-fetched on the background when one call to
# FlakeIdGenerator.newId() is made. Value must be in the range 1..100,000,
# default is 100. This setting pertains only to newId() calls made on the
# member that configured it.
prefetch-count: 100
# The validity timeout in ms for how long the pre-fetched IDs can be used.
# If this time elapses, a new batch of IDs will be fetched.
# The generated IDs contain timestamp component, which ensures rough
# global ordering of IDs. If an ID is assigned to an object that was
# created much later, it will be much out of order. If you don't care
# about ordering, set this value to 0. This setting pertains only to
# newId() calls made on the member that configured it.
prefetch-validity-millis: 600000
# Sets the offset of timestamp component. Time unit is milliseconds,
# default is 1514764800000 (1.1.2018 0:00 UTC).
epoch-start: 1514764800000
# Sets the offset that will be added to the node ID assigned to cluster
# member for this generator. Might be useful in A/B deployment scenarios
# where you have cluster A which you want to upgrade. You create cluster
# B and for some time both will generate IDs and you want to have them
# unique. In this case, configure node ID offset for generators on
# cluster B.
node-id-offset: 0
# The bit-length of the sequence component of this flake id generator.
# This configuration is limiting factor for the maximum rate at which IDs
# can be generated. Default is 6 bits.
bits-sequence: 6
# The bit-length of node id component of this flake id generator. Default
# value is 16 bits.
bits-node-id: 16
# Sets how far to the future is the generator allowed to go to generate
# IDs without blocking, default is 15 seconds.
allowed-future-millis: 15000
# Enables/disables statistics gathering for the flake-id generator on this member.
statistics-enabled: true
# The version of the portable serialization. Portable version is used to
# differentiate two same classes that have changes on it like adding/removing
# field or changing a type of a field.
serialization:
portable-version: 0
cardinality-estimator:
default:
# The number of synchronous backups. For example, if 1 is set as the
# backup-count, then the cardinality estimation will be copied to one
# other JVM for fail-safety. Valid numbers are 0 (no backup), 1, 2 ... 6.
backup-count: 1
# The number of asynchronous backups for this cardinality estimator.
async-backup-count: 0
merge-policy:
batch-size: 100
class-name: HyperLogLogMergePolicy
crdt-replication:
# The period between two replications of CRDT states in milliseconds. A
# lower value will increase the speed at which changes are disseminated to
# other cluster members at the expense of burst-like behaviour - less
# updates will be batched together in one replication message and one
# update to a CRDT may cause a sudden burst of replication messages in a
# short time interval. The value must be a positive non-null integer.
replication-period-millis: 1000
# The maximum number of target members that we replicate the CRDT states
# to in one period. A higher count will lead to states being disseminated
# more rapidly at the expense of burst-like behaviour - one update to a
# CRDT will lead to a sudden burst in the number of replication messages in
# a short time interval.
max-concurrent-replication-targets: 1
pn-counter:
default:
# Number of replicas on which the CRDT state will be kept. The updates
# are replicated asynchronously between replicas. The number must be
# greater than 1 and up to 2147483647 (Integer.MAX_VALUE). The default
# value is 2147483647 (Integer.MAX_VALUE).
replica-count: 2147483647
# True (default) if statistics gathering is enabled on the PN counter,
# false otherwise.
statistics-enabled: true
cp-subsystem:
# The number of CP members to initialize CP Subsystem. It is 0 by default,
# meaning that CP Subsystem is disabled. CP Subsystem is enabled when a
# positive value is set. After CP Subsystem is initialized successfully,
# more CP members can be added at run-time and the number of active CP
# members can go beyond the configured CP member count. The number of CP
# members can be smaller than total member count of the Hazelcast cluster.
# For instance, you can run 5 CP members in a Hazelcast cluster of 20
# members. If set, must be greater than or equal to group-size.
cp-member-count: 0
# The number of CP members to form CP groups. If set, it must be an odd
# number between 3 and 7. Otherwise, cp-member-count is respected while
# forming CP groups. If set, must be smaller than or equal to
# cp-member-count.
group-size: 0
# Duration for a CP session to be kept alive after the last received session
# heartbeat. A CP session is closed if no session heartbeat is received
# during this duration. Session TTL must be decided wisely. If a very small
# value is set, a CP session can be closed prematurely if its owner Hazelcast
# instance temporarily loses connectivity to CP Subsystem because of a
# network partition or a GC pause. In such an occasion, all CP resources of
# this Hazelcast instance, such as FencedLock or ISemaphore, are released.
# On the other hand, if a very large value is set, CP resources can remain
# assigned to an actually crashed Hazelcast instance for too long and
# liveliness problems can occur. CP Subsystem offers an API in
# CPSessionManagementService to deal with liveliness issues related to CP
# sessions. In order to prevent premature session expires, session TTL
# configuration can be set a relatively large value and
# CPSessionManagementService#forceCloseSession(String, long) can be manually
# called to close CP session of a crashed Hazelcast instance. Must be greater
# than session-heartbeat-interval-seconds, and smaller than or equal to
# missing-cp-member-auto-removal-seconds.
session-time-to-live-seconds: 300
# Interval for the periodically-committed CP session heartbeats. A CP
# session is started on a CP group with the first session-based request of
# a Hazelcast instance. After that moment, heartbeats are periodically
# committed to the CP group. Must be smaller than session-time-to-live-seconds.
session-heartbeat-interval-seconds: 5
# Duration to wait before automatically removing a missing CP member from
# CP Subsystem. When a CP member leaves the Hazelcast cluster, it is not
# automatically removed from CP Subsystem, since it could be still alive
# and left the cluster because of a network problem. On the other hand, if
# a missing CP member actually crashed, it creates a danger for CP groups,
# because it is still part of majority calculations. This situation could
# lead to losing majority of CP groups if multiple CP members leave the
# cluster over time. With the default configuration, missing CP members are
# automatically removed from CP Subsystem after 4 hours. This feature is
# very useful in terms of fault tolerance when CP member count is also
# configured to be larger than group size. In this case, a missing CP
# member is safely replaced in its CP groups with other available CP
# members in CP Subsystem. This configuration also implies that no network
# partition is expected to be longer than the configured duration. If a
# missing CP member comes back alive after it is removed from CP Subsystem
# with this feature, that CP member must be terminated manually. Must be
# greater than or equal to session-time-to-live-seconds.
missing-cp-member-auto-removal-seconds: 14400
# Offers a choice between at-least-once and at-most-once execution of
# operations on top of the Raft consensus algorithm. It is disabled by
# default and offers at-least-once execution guarantee. If enabled, it
# switches to at-most-once execution guarantee. When you invoke an API
# method on a CP data structure proxy, it sends an internal operation to
# the corresponding CP group. After this operation is committed on the
# majority of this CP group by the Raft leader node, it sends a response
# for the public API call. If a failure causes loss of the response, then
# the calling side cannot determine if the operation is committed on the CP
# group or not. In this case, if this configuration is disabled, the
# operation is replicated again to the CP group, and hence could be
# committed multiple times. If it is enabled, the public API call fails
# with com.hazelcast.core.IndeterminateOperationStateException.
fail-on-indeterminate-operation-state: false
# The CP member priority. The CP groups' leadership will be eventually
# transferred to members with higher priorities within the CP group.
cp-member-priority: 0
raft-algorithm:
# Leader election timeout in milliseconds. If a candidate cannot win
# majority of the votes in time, a new leader election round is initiated.
leader-election-timeout-in-millis: 2000
# Duration in milliseconds for a Raft leader node to send periodic
# heartbeat messages to its followers in order to denote its liveliness.
# Periodic heartbeat messages are actually append entries requests and
# can contain log entries for the lagging followers. If a too small value
# is set, heartbeat messages are sent from Raft leaders to followers too
# frequently and it can cause an unnecessary usage of CPU and network.
leader-heartbeat-period-in-millis: 5000
# Maximum number of missed Raft leader heartbeats for a follower to
# trigger a new leader election round. For instance, if
# leader-heartbeat-period-in-millis is 1 second and this value is set to
# 5, then a follower triggers a new leader election round if 5 seconds
# pass after the last heartbeat message of the current Raft leader node.
# If this duration is too small, new leader election rounds can be
# triggered unnecessarily if the current Raft leader temporarily slows
# down or a network congestion occurs. If it is too large, it takes
# longer to detect failures of Raft leaders.
max-missed-leader-heartbeat-count: 5
# Maximum number of Raft log entries that can be sent as a batch in a
# single append entries request. In Hazelcast's Raft consensus algorithm
# implementation, a Raft leader maintains a separate replication pipeline
# for each follower. It sends a new batch of Raft log entries to a
# follower after the follower acknowledges the last append entries request
# sent by the leader.
append-request-max-entry-count: 100
# Number of new commits to initiate a new snapshot after the last
# snapshot taken by the local Raft node. This value must be configured
# wisely as it effects performance of the system in multiple ways. If a
# small value is set, it means that snapshots are taken too frequently
# and Raft nodes keep a very short Raft log. If snapshots are large and
# CP Subsystem Persistence is enabled, this can create an unnecessary
# overhead on IO performance. Moreover, a Raft leader can send too many
# snapshots to followers and this can create an unnecessary overhead on
# network. On the other hand, if a very large value is set, it can create
# a memory overhead since Raft log entries are going to be kept in memory
# until the next snapshot.
commit-index-advance-count-to-snapshot: 10000
# Maximum number of uncommitted log entries in the leader's Raft log
# before temporarily rejecting new requests of callers. Since Raft
# leaders send log entries to followers in batches, they accumulate
# incoming requests in order to improve the throughput. You can configure
# this field by considering your degree of concurrency in your callers.
# For instance, if you have at most 1000 threads sending requests to a
# Raft leader, you can set this field to 1000 so that callers do not get
# retry responses unnecessarily.
uncommitted-entry-count-to-reject-new-appends: 100
# Timeout duration in milliseconds to apply backoff on append entries
# requests. After a Raft leader sends an append entries request to a
# follower, it will not send a subsequent append entries request either
# until the follower responds or this timeout occurs. Backoff durations
# are increased exponentially if followers remain unresponsive.
append-request-backoff-timeout-in-millis: 100
# semaphores:
# default:
# jdk-compatible: false
# locks:
# default:
# lock-acquire-limit: 0
# Configures Hazelcast's background collection of performance and health
# monitoring metrics.
metrics:
# Master-switch for the metrics system. Controls whether the metrics are
# collected and publishers are enabled. May be overridden by
# 'hazelcast.metrics.enabled' system property
enabled: true
management-center:
enabled: true
# Sets the number of seconds the metrics will be retained on the
# instance. By default, metrics are retained for 5 seconds (that is for
# one collection of metrics values, if default "collection-frequency-seconds"
# collection frequency is used). More retention means more heap memory,
# but allows for longer client hiccups without losing a value (for
# example to restart the Management Center). May be overridden by
# 'hazelcast.metrics.mc.retention' system property.
retention-seconds: 5
jmx:
# Controls whether the metrics collected are exposed to through JMX. It
# is enabled by default. In order to expose the metrics, the metrics
# system need to be enabled via the enabled master-switch attribute. May
# be overridden by 'hazelcast.metrics.jmx.enabled' system property.
enabled: true
# Sets the metrics collection frequency in seconds. By default, metrics are
# collected every 5 seconds. May be overridden by
# 'hazelcast.metrics.collection.frequency' system property.
collection-frequency-seconds: 5
sql:
# Sets the timeout in milliseconds that is applied to SQL statements
# without an explicit timeout. It is possible to set a timeout through the
# SqlStatement.setTimeout(long) method. If the statement timeout is not
# set, then the value of this parameter will be used. Zero value means no
# timeout. Negative values are prohibited.
statement-timeout-millis: 0
jet:
# Specifies whether if the jet is enabled or not in this member
enabled: false
# Specifies whether uploading resources when submitting the job is enabled or not
resource-upload-enabled: false
# period between flow control packets in milliseconds
flow-control-period: 100
# number of backup copies to configure for Hazelcast IMaps used internally in a Jet job
backup-count: 1
# the delay after which auto-scaled jobs will restart if a new member is added to the
# cluster. The default is 10 seconds. Has no effect on jobs with auto scaling disabled
scale-up-delay-millis: 10000
# Sets whether lossless job restart is enabled for the node. With
# lossless restart you can restart the whole cluster without losing the
# jobs and their state. The feature is implemented on top of the Persistence
# feature of Hazelcast which persists the data to disk.
lossless-restart-enabled: false
# Sets the maximum number of records that can be accumulated by any single
# Processor instance.
#
# Operations like grouping, sorting or joining require certain amount of
# records to be accumulated before they can proceed. You can set this option
# to reduce the probability of OutOfMemoryError.
#
# This option applies to each Processor instance separately, hence the
# effective limit of records accumulated by each cluster member is influenced
# by the vertex's localParallelism and the number of jobs in the cluster.
#
# Currently, maxProcessorAccumulatedRecords limits:
# - number of items sorted by the sort operation
# - number of distinct keys accumulated by aggregation operations
# - number of entries in the hash-join lookup tables
# - number of entries in stateful transforms
# - number of distinct items in distinct operation
#
# Note: the limit does not apply to streaming aggregations.
max-processor-accumulated-records: 9223372036854775807
edge-defaults:
# capacity of the concurrent SPSC queue between each two processors
queue-size: 1024
# network packet size limit in bytes, only applies to distributed edges
packet-size-limit: 16384
# receive window size multiplier, only applies to distributed edges
receive-window-multiplier: 3
# # Hazelcast 将尝试绑定的端口号。缺席审判
## 计数为 100。在此默认值下，如果将端口值设置为 5701，
## 当成员加入集群时，Hazelcast 会尝试在 5701 之间寻找端口
## 和 5801。您可以在需要大量
## 单台机器上的实例，或者您只愿意拥有几个
#已分配 # 个端口。
integrity-checker:
enabled: false
该文章已生成可运行项目，
本文章已经生成可运行项目
扫一扫
2558
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
