1.ElasticSearch源码：Shard Allocation与Rebalance(1)
2.RocksDb 源码剖析 (1) | 如何混合 new 、mmap 设计高效内存分配器 arena ?
3.UE4源码剖析：MallocBinned（上）
4.UE4 Delegate(委托)相关源码分析(一)
5.MySQL 临时表与TempTable存储引擎Allocator
6.STL源码学习（3）- vector详解

ElasticSearch源码：Shard Allocation与Rebalance(1)

       ElasticSearch源码版本 7.5.2

       遇到ES中未分配分片的情况时，特别是在大型集群中，处理起来会比较复杂。Master节点负责分片分配，通过调用allocationService.reroute方法执行分片分配，微信朋友圈游戏 源码这是关键步骤。

       在分布式系统中，诸如Kafka和ElasticSearch，平衡集群内的数据和分片分配是至关重要的。Kafka的leader replica负责数据读写，而ElasticSearch的主分片负责写入，副分片承担读取。如果集群内节点间的负载不平衡，会严重降低系统的健壮性和性能。主分片和副分片集中在某个节点的情况，一旦该节点异常，分布式系统的高可用性将不复存在。因此，分片的再平衡（rebalance）是必要的。

       分片分配（Shard Allocation）是指将一个分片指定给集群中某个节点的过程。这一决策由主节点完成，涉及决定哪个分片分配到哪个节点，以及哪个分片为主分片或副分片。

       分片分配（Shard Allocation）

       重要参数包括：cluster.routing.allocation.enable，该参数可以动态调整，控制分片的恢复和分配。重新启动节点时，此设置不会影响本地主分片的恢复。如果重新启动的节点具有未分配的主分片副本，则会立即恢复该主分片。

       触发条件

       分片分配的触发条件通常与集群状态有关，具体细节在后续段落中展开。

       分片再平衡（Shard Rebalance）

       重要参数包括：cluster.routing.rebalance.enable，用于控制整个集群的分片再平衡。再平衡的触发条件与集群分片数的变化有关，操作需要在业务低峰期进行，以减少对集群的财务系统 delphi源码影响。

       再平衡策略的触发条件主要由以下几个参数控制：

       定义分配在节点的分片数的因子阈值。

       定义分配在节点某个索引的分片数的因子阈值。

       超出这个阈值时就会重新分配分片。

       从逻辑角度和磁盘存储角度考虑，再平衡可确保集群中每个节点的分片数均衡，避免单节点负担过重。同时，确保索引的分片均匀分布，避免集中在某一分片。

       再平衡决策

       再平衡决策涉及两个关键组件：分配器（allocator）和决策者（deciders）。

       分配器负责寻找最优节点进行分片分配，通过将拥有分片数量最少的节点列表按分片数量递增排序。对于新建索引，分配器的目标是以均衡方式将新索引的分片分配给集群节点。

       决策者依次遍历分配器提供的节点列表，判断是否分配分片，考虑分配过滤规则和是否超过节点磁盘容量阈值等因素。

       手动执行再平衡

       客户端可以通过发起POST请求到/_cluster/reroute来执行再平衡操作。此操作在服务端解析为两个命令，分别对应分片移动和副本分配。

       内部模块执行再平衡

       ES内部在触发分片分配时会调用AllocationService的reroute方法来执行再平衡。

       总结

       无论是手动执行再平衡命令还是ES内部自动执行，最终都会调用reroute方法来实现分片的再平衡。再平衡操作涉及两种主要分配器（GatewayAllocator和ShardsAllocator），每种分配器都有不同的实现策略，以优化分配过程。决策者（Deciders）在再平衡过程中起关键作用，确保决策符合集群状态和性能要求。再平衡策略和决策机制确保了ElasticSearch集群的高效和稳定运行。

RocksDb 源码剖析 (1) | 如何混合 new 、mmap 设计高效内存分配器 arena ?

       本文旨在深入剖析RocksDb源码，从内存分配器角度着手。RocksDb内包含MemoryAllocator和Allocator两大类内存分配器。MemoryAllocator作为基类，提供MemkindKmemAllocator和JemallocNodumpAllocator两个子类，分别集成memkind和jemalloc库的功能，实现内存分配与释放。Python 源码C语言

       接着，重点解析Allocator类及其子类Arena的实现。基类Allocator提供两个关键接口：内存分配与对齐。Arena类采用block为单位进行内存分配，先分配一个block大小的内存，后续满足需求时，优先从block中划取，以减少内存浪费。一个block的大小由kBlockSize参数决定。分配策略中，Arena通过两个指针（aligned_alloc_ptr_和unaligned_alloc_ptr_）分别管理对齐与非对齐内存，提高内存利用效率。

       分配内存时，Arena通过构造函数初始化成员变量，包括block大小、内存在栈上的分配与mmap机制的使用。构造函数内使用OptimizeBlockSize函数确保block大小合理，减少内存对齐浪费。Arena中的内存管理逻辑清晰，尤其在分配新block时，仅使用new操作，无需额外内存对齐处理。

       分配内存流程中，AllocateNewBlock函数直接调用new分配内存，而AllocateFromHugePage和AllocateFallback函数则涉及mmap机制的使用与内存分配策略的统一。这些函数共同构成了Arena内存管理的核心逻辑，实现了灵活高效地内存分配。

       此外，Arena还提供AllocateAligned函数，针对特定对齐需求分配内存。这一函数在使用mmap分配内存时，允许用户自定义对齐大小，优化内存使用效率。在处理对齐逻辑时，Arena巧妙地利用位运算优化计算过程，提高了代码效率。

       总结而言，dsd源码 dsf dffRocksDb的内存管理机制通过Arena类实现了高效、灵活的内存分配与管理。通过深入解析其源码，可以深入了解内存对齐、内存分配与多线程安全性的实现细节，为开发者提供宝贵的内存管理实践指导。未来，将深入探讨多线程内存分配器的设计，敬请期待后续更新。

UE4源码剖析：MallocBinned（上）

       近期着手UE4项目开发，对UnrealEngine已久仰慕，终于得此机会深入探索。鉴于项目内存性能问题，决定从内存分配器着手，深入研读UE4源码。虽个人水平有限，尚不能全面理解，但愿借此机会揭开源码神秘面纱，让新手朋友们不再感到陌生。

       UE4内存分配器位于硬件抽象层HAL（Hardware Abstraction Layer）中。具体装箱内存分配器代码位于VS项目目录：UE4/Source/Runtime/Core/Private/HAL/MallocBinned。

       分析从ApplePlatformMemory::BaseAllocator开始，可发现Mac平台的默认分配器为MallocBinned，iOS的默认分配器为MallocAnsi。以下将重点分析MallocBinned。

       一、确定对齐方式

       FScopeLock用于局部线程锁，确保线程同步。关于Alignment的确定，通常使用默认值。默认值取决于内存对齐方式，此处默认对齐为8字节。

       二、确定有足够空间来内存对齐

       代码中，SpareBytesCount用于确认空间足够。若分配内存小于8字节，则按Alignment大小匹配箱体；若大于8字节，光立方app 源码则按Size + Alignment - sizeof(FFreeMem)匹配箱体。

       三、确定箱体大小

       根据Size的大小，有三种不同的处理方式。k以下的内存分配采用装箱分配，PoolTable中包含个不同大小的池子。

       四、初始化内存池

       分析内存池初始化过程，主要工作包括：确定内存大小，分配内存块，设置内存池基本信息。

       五、内存装箱

       AllocateBlockFromPool从内存池中分配一个Block，实现内存装箱过程。

UE4 Delegate(委托)相关源码分析(一)

       UE4委托是强效设计，尤其在大型项目中大放异彩。无论是模块解耦、扩展接口还是实现替换自定义实现，其价值巨大。未使用委托的程序员，当功能复杂且相互关联时，项目管理必定混乱。C++中，委托实现基于函数指针，核心是存储并调用。然而，成员函数指针的存在让C++委托实现变得独特而高效。UE4内置强大、实用的代理机制，本系列旨在深入解析代理源码，并提供实例应用。

       打开代理宏定义文件，虽近行，主体类型仅几种。定义事件`DECLARE_EVENT`显得特别，其用途似乎不小但使用未广泛。事件与组播委托相似，但允许仅定义事件的类调用`Broadcast`、`IsBound`和`Clear`函数，限制外部类对这些函数的访问，便于在公共接口中公开事件。测试发现，外部仍然能调用这些函数，官方文档描述与实际不符。不确定是否为版本更新或使用方法问题。

       普通单播代理定义`TBaseDelegate`模板类，继承`FDelegateBase`，使用`DelegateAllocator`存储`IDelegateInstance`对象，其中包含代理实现。普通多播代理则定义`TMulticastDelegate`模板类，继承`TBaseMulticastDelegate`，核心是`TInvocationList`数组，存储多个代理处理对象，并通过添加和删除函数维护数组，实现多播逻辑。广播时，遍历数组依次调用各代理处理对象。使用多播时，只需考虑绑定代理，无需解绑，无效代理会自动移除。

       动态单播代理定义类`TBaseDynamicDelegate`，继承`TScriptDelegate`，存储`TWeakPtr(UObject指针)`和`FName(函数名称)`，通过反射系统找到对应`UFunction`执行。动态代理依赖UE4强大反射系统，绑定函数需加上`UFUNCTION()`宏。绑定函数时，`AddDynamic`等宏将函数指针转换为函数名称，或直接传递函数名称并调用`BindFunction`。动态多播可通过添加`BlueprintAssignable`标记，让蓝图使用并绑定。

       UE4委托实现多样，但核心在于管理回调，实现模块解耦与功能扩展。掌握其原理与应用，有助于更高效地构建大型项目。

MySQL 临时表与TempTable存储引擎Allocator

       MySQL临时表与TempTable存储引擎Allocator

       MySQL Community 8.0.版本中，临时表的创建可使用CREATE TEMPORARY TABLE语句。这些表在当前会话中可见，且在会话结束时自动删除。多个会话中可以使用相同的临时表名。默认存储引擎自8.0.版本起为TempTable。

       在执行某些SQL语句时，MySQL可能隐式创建临时表，用户无法直接控制。例如，查询或子查询可能触发隐式临时表的创建。使用EXPLAIN语句检查EXTRA列，若显示Using temporary，则说明使用了临时表。

       早期版本使用Memory作为默认临时表存储引擎。然而，TempTable存储引擎引入于MySQL 8.0.版本后，提供了更高效和灵活的内存分配策略。

       TempTable内存分配策略由Allocator类负责，该类内部包含分配机制控制类AllocationScheme。block_size()方法设定每次分配的块大小，而block_source()方法则指定存储介质的使用策略。

       默认情况下，Allocator使用Exponential_growth_preferring_RAM_over_MMAP策略，优先在RAM中分配空间。RAM空间不足或不使用mmap文件时，会转而尝试在mmap文件上分配空间。若RAM空间使用率超过temptable_max_ram阈值，将优先使用RAM空间。

       当RAM空间已满或mmap文件空间不足时，TempTable会抛出Result::RECORD_FILE_FULL异常。此时，MySQL会将临时表迁移至磁盘上，利用InnoDB存储引擎创建新表，并将数据迁移到新表中，以继续存储超出内存限制的数据。

       在MySQL的源代码中，可以找到TempTable存储引擎与内存、磁盘空间分配相关的具体实现细节。例如，在storage/temptable路径下的代码展示了如何使用Allocator类来管理内存分配，并在必要时迁移至磁盘。

       在服务器层的代码逻辑中，当尝试向已满的内存表写入数据时，会调用create_ondisk_from_heap()函数，将表迁移至磁盘上的新表中，确保数据的连续存储与访问。

       总之，MySQL的临时表与TempTable存储引擎Allocator通过灵活的内存管理和磁盘迁移策略，提供高效的数据存储与查询能力，适应了不同场景下的性能需求。

STL源码学习（3）- vector详解

       STL源码学习（3）- vector详解

       vector的迭代器与数据类型：vector内部的连续存储结构使得任何类型的数据指针都可以作为其迭代器。通过迭代器，可以执行诸如指针操作，如访问元素值。

       vector定义了两个迭代器start和finish，分别指向元素的起始和终止地址，同时还有一个end_of_storage标记空间的结束位置。vector的容量保证大于等于已分配元素空间，提供了获取空间大小的函数，如front和back的值以引用返回，更高效。

       空间配置原理：STL中的vector使用SGI STL容器的二级空间配置器。vector头部包含配置信息，如data_allocator作为空间配置器的别名。简单配置器（simple_alloc）是封装了高级和低级配置器调用的抽象类。

       构造函数与内存管理：vector通过空间配置器创建元素。构造函数允许预分配并初始化元素，fill_initialize用于调整空间范围，allocate_and_fill则分配空间并填充。这个过程涉及data_allocator的allocate函数，分配空间并返回起始地址。

       vector析构时，调用deallocate函数释放空间。pop_back和erase方法会移除元素并销毁相应空间，clear则清除全部元素。insert操作复杂，根据元素数量和容器状态可能需要扩容。

       插入与扩展操作：push_back在末尾插入元素，如果空间不足，可能需要扩容。insert接受三个参数，根据情况处理插入操作，可能抛出异常并销毁部分元素。

STL源码剖析总结笔记（5）：认识迭代器的好帮手--list

       在深入探讨STL中的`list`容器之前，我们先简要回顾了`vector`的特性以及分配器（`allocator`）的作用。接下来，我们将转向一个具有代表性的容器——`list`。之所以说其具有代表性，是因为`list`利用非连续的空间存储元素，从而在空间利用上更为精确。学习`list`是掌握迭代器机制的第一步。

       “list”实质上是双向链表，它具有两个重要特性：前向指针和后向指针。在STL中，`list`节点的定义可能使用`_list_node*`（可能为了兼容性或设计规范）来指代节点结构，其中包含了指向下一个节点和上一个节点的指针。

       `list`的内部实现为一个环状的双向链表结构，通过一个指向虚拟尾节点的指针`node`来方便遍历。`begin()`和`end()`方法的实现依赖于这个`node`。此外，`empty()`、`size()`、`front()`（访问头节点内容）、`back()`（访问尾节点内容）等方法的实现相对直截了当。

       `list`的迭代器（`iterator`）设计得更为复杂，因为非连续的空间分配使得简单指针的操作无法直接使用。迭代器需要智能地追踪当前节点及其前后的节点，以便进行递增、递减和取值操作。这要求迭代器实现诸如`++`和`--`等操作符的重载，同时还需要定义至少1-5个`typedef`类型来支持迭代器的基本行为。

       `++`操作符的重载遵循前置`++`和后置`++`的区别：前置`++`直接返回计算后的结果（即更新后的迭代器），而后置`++`返回迭代器的副本，避免了在C++中直接对整数进行两次后置`++`的操作，因为这会导致未定义的行为。`*`和`->`操作符用于访问当前节点的数据和成员，后者通过`*`操作符访问节点数据后再通过指针访问成员，确保了数据的安全访问。

       `list`的基本操作主要依赖于节点指针的移动和修改，如插入、删除等。这些操作通常需要考虑双向链表的特性以及虚拟尾节点的存在，以避免丢失数据或产生无效指针。例如，`transfer()`方法是一个关键功能，允许将一段连续范围的元素移动到链表中的特定位置，这是许多其他复杂操作的基础。

       在`list`中，`transfer()`方法实现了将`[first,last)`范围内的元素移动到指定位置的逻辑，通过调整节点的`next`和`prev`指针来完成移动，同时确保了数据的完整性。基于`transfer()`方法，其他高级操作也能够实现，尽管这些操作通常不直接暴露给用户，而是通过封装在`list`内部的实现来提供。

       学习`list`不仅有助于理解迭代器的设计原理，也为探索其他容器（如`vector`和`deque`）的实现提供了基础。在接下来的内容中，我们将详细探讨迭代器的实现技巧，以及如何在实际编程中利用这些概念来优化代码。