# 第一部分 概述
将长链接转换为短链接是一种常见的需求，通常用于在限制长度的场景下分享链接，或者简化链接以提高用户体验。本篇文章讨论几种相对通用的实现方式（第三方服务不在讨论范围）。




# 第二部分 常用方案


:::tip{title="提示"}
生成短链接时，确保其唯一性和尽可能短是非常关键的。
:::

## 2.1 基于时间戳+随机数/计数器

**方案说明**：
- **时间戳**: 使用当前时间的时间戳作为基础部分，确保了每个短链接的生成时间不同，自然具有一定的唯一性。
- **随机数/计数器**: 在时间戳基础上附加一个较短的随机数或递增计数器，以应对同一毫秒内生成多个短链接的情况，确保唯一性。

**优点**：
- 利用时间戳的天然顺序，易于排序和管理。
- 随机数或计数器的加入，提高了并发情况下的唯一性保障。

**缺点**：
- 时间戳部分较长，可能影响短链接的简洁度。

## 2.2 Base62编码

**方案说明**：
- 将长整型`ID`（如`基于时间戳+计数器`生成的`ID`）转换为`Base62`编码。`Base62`包含小写字母、大写字母和数字（共`62`个字符），比传统的`Base16`（十六进制）或`Base32`能更高效地利用字符空间，使得同样的数字可以表示更短的字符串。

**优点**：
- 极大地缩短了编码长度，提升了短链接的简洁性。
- 可以通过逆向解码恢复原始`ID`，便于查询和管理。

**缺点**：
- 需要处理潜在的冲突问题，尤其是在高并发场景下。


:::info{title="相关信息"}
`Base62`是一种将数字和字母混合起来的编码方式，使用了`62`个字符，包括小写字母、大写字母和数字`0-9`。`Base62`编码常用于将较长的数字或数据转换为更短、更易于处理和传输的字符串表示形式。

**使用场景**
- **短链接生成**：`Base62`编码常用于生成短链接，将长网址转换为短字符串，方便分享和传播。短链接不仅更美观，而且更易于记忆和传输，因此在分享网址时非常流行。
- **密钥生成**：`Base62`编码可用于生成密钥或令牌，用于安全验证或身份验证。例如，生成访问令牌、`API`密钥或会话标识符等。
- **文件名生成**：`Base62`编码可用于生成独一无二的文件名，避免文件名冲突和重复，同时保持文件名的简洁和易读性。
- **数据转换**：在数据传输过程中，`Base62`编码可用于将二进制数据或大整数转换为字符串形式，方便存储、传输和解析。
- **短字符串存储**：在数据库中存储较短的标识符或键值对时，`Base62`编码可节省存储空间，并提高查询和索引的效率。
- 
总的来说，`Base62`编码适用于需要将较长的数字或数据转换为短、易于处理和传输的字符串形式的场景。它具有良好的可读性、节省存储空间的优势，并广泛应用于短链接生成、密钥生成、文件名生成等领域。
:::

## 2.3 自增ID+连续哈希映射

**方案说明**：
- 维护一个全局自增ID作为长链接的标识。
- 使用连续哈希映射（如一致性哈希）将这个`ID`映射到一个较短的字符串空间中，确保映射的一致性和高效查询。

**优点**：
- 通过连续哈希映射，可以在保持唯一性的前提下，有效控制短链接的长度。
- 易于扩展和维护。

**缺点**：
- 实现相对复杂，需要考虑哈希环的平衡性和扩展性。

:::info{title="相关信息"}
连续哈希映射是一种多次应用哈希函数的方法，其中每次哈希函数的输出作为下一次哈希函数的输入。通过多次哈希映射，可以进一步增加哈希函数的分散性和唯一性，从而提高哈希算法的安全性和性能。

**示例**
假设有一个长字符串需要哈希，我们可以将该字符串首先应用第一个哈希函数，然后将结果再次应用到第二个哈希函数，以此类推，直到达到预定的哈希次数或达到某个条件为止。最终的哈希值即为连续哈希映射的结果。

**使用场景**
- **密码学中的加密算法**：连续哈希映射可以用于密码学中的加密算法，如密码哈希函数。例如，在密码存储过程中，可以多次应用哈希函数对密码进行哈希，增加密码的安全性。
- **数据完整性校验**：在数据传输过程中，可以使用连续哈希映射来对数据进行完整性校验。发送方可以将数据连续哈希映射后的结果附加到数据中，接收方可以再次对接收到的数据应用相同的连续哈希映射，以验证数据的完整性。
- **分布式系统中的数据分片**：在分布式系统中，可以使用连续哈希映射来将数据分配到不同的节点或分片中。通过多次哈希映射，可以使数据更均匀地分布在不同的节点中，提高系统的负载均衡性和性能。

总的来说，连续哈希映射适用于需要增加哈希函数分散性和唯一性的场景，如密码学、数据完整性校验和分布式系统中的数据分片等领域。通过多次应用哈希函数，可以提高数据的安全性、完整性和性能。
:::

## 2.4 哈希算法+自定义规则

**方案说明**：
- 使用`MD5`或`SHA-256`等安全哈希算法处理长链接或其`ID`，然后取哈希值的前几位作为短链接的基础。
- 可以根据需要，对哈希值进行自定义规则处理，如替换、移位等，进一步增加唯一性并缩短长度。

> 在`Hash`算法选择中，通常会使用`MurmurHash`算法生成长链接的`hash`值。 

**优点**：
- 哈希算法保证了良好的唯一性。
- 自定义规则可以灵活调整以适应不同的长度要求。

**缺点**：
- 存在极小概率的哈希碰撞问题，需要额外机制处理。


:::info{title="相关信息"}

`MurmurHash`是一种快速非加密型哈希函数，由`Austin Appleby`在2008年创建。它被设计用于高速哈希算法中，具有良好的散列性能和低碰撞率。`MurmurHash`在计算哈希值时非常快速，并且在处理非常大的数据集时具有良好的性能。

**简介**

`MurmurHash`算法的核心思想是通过混合、变换和组合输入数据的各个部分来计算哈希值。它采用了一系列位操作、移位操作、异或运算和乘法等简单的数学运算，以及一个具有良好随机性的特定常数作为种子来实现哈希计算。`MurmurHash`算法的设计目标是高速、可靠和具有良好的分布特性。

**适应场景**

`MurmurHash`算法适用于许多场景，包括但不限于：
- **哈希表**：用于实现哈希表数据结构，用于快速查找和存储键值对。
- **数据分布**：用于分布式系统中的数据分区和负载均衡，确保数据分布均匀。
- **哈希检验**：用于数据完整性检验，如校验和计算、文件校验等。
- **哈希索引**：用于构建索引数据结构，提高检索效率。

**优点**

- **速度快**：`MurmurHash`算法在计算哈希值时非常快速，适用于需要高效处理大量数据的场景。
- **低碰撞率**：`MurmurHash`算法具有良好的散列性能，碰撞率较低，适用于要求较高的哈希算法场景。
- **分布均匀**：`MurmurHash`算法生成的哈希值分布均匀，有利于提高数据的均匀分布性，降低哈希冲突的概率。

**总结**

`MurmurHash`算法是一种快速、可靠且具有良好散列性能的哈希算法，适用于各种需要哈希计算的场景。它的速度快、碰撞率低以及分布均匀等特点使得它成为了许多哈希算法的首选之一。无论是在哈希表、数据分布、哈希检验还是哈希索引等领域，`MurmurHash`都展现出了出色的性能和应用价值。
:::

# 第三部分 综合方案

在实际应用中，通常会结合上述多种方法，例如先使用时间戳加计数器生成`ID`，然后将`ID`进行`Base62`编码，同时设计一套冲突检测和解决机制（如在数据库中检查`ID`是否已存在），确保生成的短链接既唯一又尽量短。此外，还可以引入布隆过滤器等数据结构来快速判断`ID`是否存在，减少数据库查询压力。

## 3.1 MurmurHash+Base62编码

使用`MurmurHash`和`Base62`结合的方法生成短链接是一种常见的做法，这样可以保证生成的短链接具有较高的唯一性和易读性。下面是使用`MurmurHash`和`Base62`结合的方法生成短链接的示例代码：

```java
long hash = MurmurHash.hash32("https://blog.jianggujin.com/post/5");
System.out.println("长链接hash:" + hash);
byte[] bytes = ByteBuffer.allocate(Long.BYTES).putLong(hash).array();
String encoded = Base62.encode(bytes);
System.out.println("转换后编码:" + encoded);

hash = MurmurHash.hash64("https://blog.jianggujin.com/post/5");
System.out.println("长链接hash:" + hash);
bytes = ByteBuffer.allocate(Long.BYTES).putLong(hash).array();
encoded = Base62.encode(bytes);
System.out.println("转换后编码:" + encoded);
```

运行示例代码观察控制台输出

```
长链接hash:640577084
转换后编码:0000hLnMS
长链接hash:-4731572046405325430
转换后编码:GL9dGlAe8Yk
```

> 示例代码中的`MurmurHash`和`Base62`使用`hutool`工具实现，在进行`hash`处理时，可根据实际情况选择`hash32`或`hash64`。

:::warning{title="注意"}
虽然`MurmurHash`和`Base62`结合的方式生成短链接具有较高的唯一性，依然存在冲突的可能，在实际使用过程中需要考虑发生冲突后的处理，比如增加自增整数等。
:::

## 3.2 自增ID+Base62编码

使用自增`ID`和`Base62`结合的方法生成短链接是另一种常见的做法，相较于使用`MurmurHash`和`Base62`结合的方法，采用自增`ID`的方式可确保生成的短链的唯一性。自增`ID`的生成可以利用数据库、`Redis`、雪花算法等方式生成。下面是使用雪花算法和`Base62`结合的方法生成短链接的示例代码：

```java
long hash = IdWorker.getId();
System.out.println("长链接hash:" + hash);
byte[] bytes = ByteBuffer.allocate(Long.BYTES).putLong(hash).array();
String encoded = Base62.encode(bytes);
System.out.println("转换后编码:" + encoded);
```

运行示例代码观察控制台输出

```
长链接hash:1787313950076686338
转换后编码:281uqNpdic6
```

> 使用自增`ID`和`Base62`结合的方式，短链接的`hash`值的生成与链接本身无关

长链接转短链接方案

Java脚本引擎与动态编译

# 第一部分 概述

`OpenLDAP`客户端和服务器能够使用传输层安全（`TLS`）框架来提供完整性和机密性保护，并使用`SASL`外部机制支持`LDAP`身份验证。本文介绍如何启用`LDAP`的安全连接，访问[LDAP官方文档](https://www.openldap.org/doc/admin26/tls.html)查看完整配置。

`LDAP`的安全连接有两种方式：

- 启用标准`ldap:///`连接，即监听所有网络接口上的`LDAP`标准端口 `389`，通过 `StartTLS`对通信内容进行加密处理，避免明文传输。

- 启用`ldaps:///`连接，在`TLS`中传输`LDAP`协议，默认端口为`636`。





## 1.1 传输层安全协议

`TLS`是传输层安全协议（`Transport Layer Security`），也经常与其前身安全套接层（`SSL，Secure Sockets Layer`）的并列，写作`TLS/SS`L。有时也直接以`SSL`代之。该协议广泛应用于电子邮件、即时通信等应用中，最常见的场景就是`HTTPS`。`SSL`系列协议由于年代久远且屡屡爆出安全隐患问题，自2015年后已被全面弃用。

`TLS`协议旨在运用证书来提供加密，保护端对端的通信秘密、完整和认证功能，免受第三方的窥探和篡改。`TLS`在 1999 年被互联网工程任务组（`IETF，Internet Engineering Task Force`）确立为标准之一。目前最新的`TLS`版本为`1.3`，为同时兼顾安全性和兼容性，本文遵循 ***[Mozilla SSL 配置生成器](https://ssl-config.mozilla.org/)***，采用同时启用`TLS 1.2`和`TLS 1.3`的中间（`Intermediate`）配置。

# 第二部分 配置安全连接

## 2.1 签发证书（自签名证书，如已有证书，则忽略此步骤）

> <span style="color:red;">自己签发的证书，是不受其他服务器信任的，生产环境不建议采用自签名证书。**此步骤仅供参考，需要根据实际情况进行调整**</span>

在`LDAP`编译时已启用`TLS`，并采用`OpenSSL`(`--with-tls=openssl`)，所以此处以`OpenSSL`命令行工具为例，签发根证书和服务器证书。首先为根证书编写`OpenSSL`配置文件。

```toml
[ req ]
distinguished_name  = req_distinguished_name
string_mask         = utf8only
x509_extensions     = v3_ca
prompt              = no

[ req_distinguished_name ]
countryName                     = CN
stateOrProvinceName             = Nanjing
localityName                    = Nanjing
organizationName                = Jianggujin
organizationalUnitName          = Jianggujin
commonName                      = Jianggujin Certificate Authority
emailAddress                    = ldap@jianggujin.com

[ v3_ca ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true
keyUsage = critical, digitalSignature, keyCertSign
```

将上述内容保存为 `ca.conf` 文件，然后执行如下命令，生成根证书的`4096`位`RSA`私钥，并签发根证书。

```sh
$ openssl genrsa -out ca.key 4096
$ openssl req -x509 -new -sha512 -nodes -key ca.key -days 7307 -out ca.crt -config ca.conf
```

接下来给服务器证书编写`OpenSSL`配置。此处要注意<span style="color:red;"> **commonName** 和 **sans** 部分应与服务器的主机名一致</span>。

```toml
[ req ]
prompt              = no
days                = 365
default_md          = sha256
distinguished_name  = req_distinguished_name
x509_extensions      = v3_server

[ req_distinguished_name ]
countryName                     = CN
stateOrProvinceName             = Nanjing
localityName                    = Nanjing
organizationName                = Jianggujin
organizationalUnitName          = Jianggujin
commonName                      = ldap.jianggujin.com
emailAddress                    = ldap@jianggujin.com

[ v3_server ]
basicConstraints = CA:false
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer:always
keyUsage = critical, digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth, clientAuth
subjectAltName = @sans

[ sans ]
DNS.0 = ldap.jianggujin.com
```

将上述内容保存为 `server.conf` 文件后，然后执行如下命令，先签发服务器证书请求，再用根证书签发服务器证书。

```shell
$ openssl genrsa -out server.key 2048
$ openssl req -config server.conf -key server.key -new -out server.csr
$ openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -out server.crt -extfile server.conf -extensions v3_server -CAcreateserial
```

最后使用根证书验证服务器证书是否有效。

```shell
$ openssl verify -CAfile ca.crt server.crt
server.crt: OK
```

如此，根证书和服务器证书就都签发成功了。

## 2.2 配置TLS

编写如下`LDIF`文件，分别添加 `olcTLSCACertificateFile`、`olcTLSCertificateFile` 和 `olcTLSCertificateKeyFile` 属性，对应 `CA 证书文件`、`服务器证书文件`、`服务器私钥文件`。

```
dn: cn=config
changetype: modify
add: olcTLSCACertificateFile
olcTLSCACertificateFile: /opt/openLDAP/cert/ca.crt # 修改为实际路径
-
add: olcTLSCertificateFile
olcTLSCertificateFile: /opt/openLDAP/cert/server.crt # 修改为实际路径
-
add: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /opt/openLDAP/cert/server.key # 修改为实际路径
-
add: olcTLSCipherSuite
olcTLSCipherSuite: ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384
-
add: olcTLSDHParamFile
olcTLSDHParamFile: /opt/openLDAP/cert/ffdhe2048.txt # 该文件参见下文获取方式
```

将上述内容保存为 `tls.ldif` 文件后，然后执行如下命令，修改LDAP已有配置。

```shell
$ /opt/openLDAP/sbin/slapmodify -n 0 -l tls.ldif
```

在上述配置中，除了添加证书配置外，用`olcTLSCipherSuite`指定密码套件。此处填写的密码套件是`OpenSSL`格式的。这些密码套件中都使用了瞬现迪菲-赫尔曼密钥交换（`DHE，Ephemeral Diffie-Hellman`）和瞬现椭圆曲线迪菲-赫尔曼密钥交换（`ECDHE，Elliptic Curve Ephemeral Diffie-Hellman`），能提供完全向前保密（`PFS，Perfect Forward Secrecy`），即便私钥暴露，攻击者也不能解密暴露之前的会话内容。

为此，需要用`olcTLSDHParamFile`指定DH参数。因为服务器私钥为`2048`位，也要选择相同位数的DH参数。可以从[ ***Mozilla 下载***](https://ssl-config.mozilla.org/ffdhe2048.txt)这个参数。

## 2.3 配置安全高强度系数

`OpenLDAP`中的安全强度系数（`SSF，Security Strength Factor`）用于控制特定操作的密钥强度下限。在`olcSecurity`中可以配置一组系数，控制不同的操作。

下面列出了几种常见的安全强度系数。

- **ssf**：全局安全强度系数。
- **tls**：`TLS`安全强度系数。
- **update_ssf**：更改内容所需的安全强度系数。
- **simple_bind**：简单认证（即用户名/密码认证）所需的安全强度系数。

简单起见，本文直接配置与密码套件对应的全局安全强度系数，全局禁用了明文操作

> 0 (zero) implies no protection, 1 implies integrity protection only, 56 DES or other weak ciphers, 112 triple DES and similar ciphers, 128 RC4, Blowfish and other similar ciphers, 256 modern ciphers

```
dn: cn=config
changetype: modify
add: olcSecurity
olcSecurity: ssf=128
```

将上述内容保存为 ssf.ldif 文件后，然后执行如下命令，修改LDAP已有配置。

```shell
$ /opt/openLDAP/sbin/slapmodify -n 0 -l ssf.ldif
```

## 2.4 测试TLS 配置

启动`LDAP`服务，启动命令中增加`-h`参数，同时启用`ldap:///`和`ldaps:///`

```shell
$ cd /opt/openLDAP/libexec && ./slapd -h "ldap:/// ldaps:///"
```

> 当不指定`-h`参数运行`slapd`时，默认端点为 `ldap:///`，即监听所有网络接口上的`LDAP`标准端口 `389`，并支持 `StartTLS`。使用上述方式可同时启用，开放`ldaps:///`的端口`636`（注意：需要增加防火墙配置）

### 2.4.1 使用ldapsearch测试连接

```shell
$ /opt/openLDAP/bin/ldapsearch -x -H ldap://ldap.jianggujin.com -D "cn=config" -W -b "cn=schema,cn=config"
Enter LDAP Password:
ldap_bind: Confidentiality required (13)
        additional info: confidentiality required
```

命令中的参数意义如下。

- **-x**：使用简单认证。
- **-H**：服务器地址，为空则表示本机。
- **-D**：要绑定的 DN。
- **-W**：提示输入绑定密码。

返回状态码为 `13`，服务器拒绝了明文连接，并要求使用加密连接则表示配置安全强度系数生效。增加 `-ZZ` 参数，使用`TLS`向服务器发起请求，并在发起`TLS`连接失败的情况下退出。

```shell
$ /opt/openLDAP/bin/ldapsearch -x -H ldap://ldap.jianggujin.com -D "cn=config" -W -b "cn=schema,cn=config" -ZZ
```

连接成功则配置完成，此处需要注意，如果出现证书验证失败问题，尝试将证书导入系统后重试。

```shell
$ cp ca.crt /etc/pki/ca-trust/source/anchors/ 
$ update-ca-trust extract
```

经过上述步骤操作后如依然出现无法连接，提示信息如下：

```shell
$ /opt/openLDAP/bin/ldapsearch -x -H ldap://ldap.jianggujin.com -D "cn=config" -W -b "cn=schema,cn=config" -ZZ
ldap_start_tls: Connect error (-11)
        additional info: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed (self signed certificate in certificate chain)
```

该错误是因为我们的自签名证书不受信导致的，可以尝试修改`LDAP`客户端的配置，添加`TLS_CACERT`并指定`CA`证书，该值等价于配置`TLS`中的`olcTLSCACertificateFile`参数。

```shell
$ vi /opt/openLDAP/etc/openldap/ldap.conf
```

在其中增加一行

```
TLS_CACERT  /opt/ca/ca.crt  # 修改为实际路径 
```

修改完成并保存后，重试命令。

除了使用`-ZZ`参数开启`startTLS`外，也可以使用下面的命令测试LDAPS连接

```shell
$ /opt/openLDAP/bin/ldapsearch -x -H ldaps://ldap.jianggujin.com -D "cn=config" -W -b "cn=schema,cn=config"
```

### 2.4.2 使用ApacheDirectoryStudios测试连接

> 连接过程如提示信任证书选择全部信任


![ldap-tls01.png](/static/img/07570304df93efd0ed281c4104a26603.ldap-tls01.webp)

图一：`ldap:///`并使用`StartTLS`方式连接


![ldap-tls02.png](/static/img/155dd542f9fdeb7869211628bcc6501c.ldap-tls02.webp)

图二：`ldaps:///`方式连接

### 2.4.3 Java代码测试连接(novell ldaps)

```java
LDAPConnection conn = new LDAPConnection(new LDAPJSSESecureSocketFactory(new DefaultSSLFactory())); # cn.hutool.http.ssl.DefaultSSLFactory
conn.connect("172.31.24.194", 636);
conn.bind(LDAPConnection.LDAP_V3, "cn=config", "jianggujin".getBytes("UTF-8"));
```

### 2.4.4 Java代码测试连接(novell ldap+startTLS)

```java
LDAPConnection conn = new LDAPConnection(new LDAPJSSEStartTLSFactory(new DefaultSSLFactory())); # cn.hutool.http.ssl.DefaultSSLFactory
conn.connect("172.31.24.194", 389);
conn.startTLS();
conn.bind(LDAPConnection.LDAP_V3, "cn=config", "jianggujin".getBytes("UTF-8"));
```

### 2.4.5 Java代码测试连接(原生StartTLS模式)

```java
Hashtable<String, String> env = new Hashtable<>();
env.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.ldap.LdapCtxFactory");

// Must use the name of the server that is found in its certificate
env.put(Context.PROVIDER_URL, "ldap://172.31.24.194:389");
// Create initial context
LdapContext ctx = new InitialLdapContext(env, null);

// Start TLS
StartTlsResponse tls = (StartTlsResponse) ctx.extendedOperation(new StartTlsRequest());
tls.setHostnameVerifier((s, d) -> true);
tls.negotiate(new DefaultSSLFactory()); # cn.hutool.http.ssl.DefaultSSLFactory

// Perform simple client authentication
ctx.addToEnvironment(Context.SECURITY_AUTHENTICATION, "simple");
ctx.addToEnvironment(Context.SECURITY_PRINCIPAL, "cn=directory manager,dc=jianggujin,dc=com");
ctx.addToEnvironment(Context.SECURITY_CREDENTIALS, "jianggujin");
// do something
ctx.close();
```

### 2.4.6 Java代码测试连接(原生ldaps模式)

自定义`SocketFactory`（用于忽略证书验证，如生产环境不需要则忽略该步骤，需要将证书导入`Java`证书库）

```java
import cn.hutool.http.ssl.DefaultSSLFactory;

import javax.net.SocketFactory;
import java.io.IOException;
import java.net.InetAddress;
import java.net.Socket;
import java.net.UnknownHostException;

public class CustomSocketFactory extends SocketFactory {
    private DefaultSSLFactory factory;

    /**
     * 该方法非常重要，不能删除，且返回类型为当前类，否则会不匹配导致类转换错误
     **/
    public static SocketFactory getDefault() {
        return new CustomSocketFactory();
    }

    public CustomSocketFactory() {
        factory = new DefaultSSLFactory();
    }

    @Override
    public Socket createSocket(String s, int i) throws IOException, UnknownHostException {
        return factory.createSocket(s, i);
    }

    @Override
    public Socket createSocket(String s, int i, InetAddress inetAddress, int i1)
            throws IOException, UnknownHostException {
        return factory.createSocket(s, i, inetAddress, i1);
    }

    @Override
    public Socket createSocket(InetAddress inetAddress, int i) throws IOException {
        return factory.createSocket(inetAddress, i);
    }

    @Override
    public Socket createSocket(InetAddress inetAddress, int i, InetAddress inetAddress1, int i1) throws IOException {
        return factory.createSocket(inetAddress, i, inetAddress1, i1);
    }
}
```

测试代码如下：

```java
Hashtable<String, Object> env = new Hashtable<>();
env.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.ldap.LdapCtxFactory");
env.put(Context.PROVIDER_URL, "ldaps://172.31.24.194:636");
env.put(Context.SECURITY_AUTHENTICATION, "simple");
env.put(Context.SECURITY_PRINCIPAL, "cn=directory manager,dc=jianggujin,dc=com");
env.put(Context.SECURITY_CREDENTIALS, "jianggujin");
env.put("java.naming.ldap.factory.socket", CustomSocketFactory.getClass().getName());
// Create initial context
LdapContext ctx = new InitialLdapContext(env, null);
// do something;
ctx.close();
```

# 第三部分 引用
1. [OpenLDAP 从零开始：（一）TLS 配置](https://lab.jinkan.org/2022/09/15/openldap-from-scratch-1/)

OpenLdap启用安全连接

# 第一部分 概述

`OpenLdap`的数据同步功能是实现多服务器环境下数据一致性的关键技术。通过合理选择和配置同步方案，企业可以确保其`LDAP`服务的稳定性、可靠性和高效性。无论是简单的一主多从模式，还是复杂的多主模式，都需要根据实际的业务需求和系统环境来进行选择。在配置同步方案时，应当注意同步参数的正确设置，以及冲突解决策略的制定。同时，定期的监控和维护也是确保数据同步正常运行的重要环节。



# 第二部分 常见同步模式与组合方案
## 2.1 常见同步模式
### 2.1.1 一主多从（Master-Slave）模式

**适用场景**

这种模式适用于需要将一个主服务器的数据复制到多个从服务器的场景。在这种模式下，所有的更改都在主服务器上进行，然后同步到从服务器。这有助于减轻主服务器的负担，同时确保数据的一致性。

**优点**

- **简单易配置**：一主多从模式相对容易设置和维护。
- **读写分离**：从服务器可以处理读取请求，减轻主服务器的压力。
- **高可用性**：如果主服务器出现故障，可以快速切换到从服务器，保证服务的连续性。

**缺点**

- **单点故障**：主服务器若出现故障，所有同步都会受到影响。
- **延迟问题**：数据同步可能存在延迟，特别是在网络状况不佳的情况下。
- **只读从服务器**：从服务器通常只处理读取请求，不支持写入操作。

### 2.1.2 双主（Dual-Master）模式

**适用场景**

双主模式适用于需要两个或多个服务器都能独立处理写入操作的场景。这种模式下，每个服务器都可以接收更新，并同步到其他服务器。

**优点**

- **增强容错能力**：如果一个主服务器宕机，另一个可以继续处理更新。
- **负载均衡**：多个主服务器可以分担写入负载，提高系统性能。
- **地域分布**：可以在不同地理位置部署主服务器，减少网络延迟。

**缺点**

- **配置复杂**：双主模式的配置和管理相对复杂。
- **数据冲突**：在网络分区或服务器时钟不同步的情况下，可能会出现数据冲突。
- **同步开销**：需要更多的资源和带宽来处理多个服务器之间的同步。

### 2.1.3 多主（Multi-Master）模式

**适用场景**

多主模式适用于需要多个服务器同时处理写入操作的场景，且这些服务器之间需要实时同步数据。

**优点**

- **实时同步**：所有服务器都能实时接收和处理更新。
- **高度可用**：系统更加健壮，任何一个服务器的故障都不会影响整体服务。
- **分布式处理**：可以有效利用多个服务器的资源，提高数据处理能力。

**缺点**

- **配置和管理难度大**：多主模式的配置和管理是最复杂的。
- **冲突解决**：需要有效的冲突解决机制来处理数据同步过程中的冲突。
- **成本较高**：需要更多的硬件资源和网络带宽。

## 2.2 常见组合方案

- **主从+双主组合**：在一个大型的`LDAP`部署中，可以结合使用主从和双主模式。例如，可以将一个数据中心的服务器配置为双主模式，而将其他数据中心的服务器配置为从主数据中心的主服务器同步数据。
- **分层同步**：在大型组织中，可以采用分层同步的方式，即顶层服务器作为主服务器，下层服务器根据地理位置或组织结构作为从服务器或其他主服务器。


:::tip{title="提示"}
本节介绍的同步为生产中常见的同步模式，除了介绍的这些，在`OpenLdap`中还支持其他的同步模式，具体内容可参见[官网文档](https://www.openldap.org/doc/admin25/replication.html)。
:::

# 第三部分 数据同步配置

在第一部分中介绍了`OpenLdap`数据同步的常见组合模式，看上去较为复杂，对整体的同步模式进行拆解后可以发现，在数据同步的整体架构中，`OpenLdap`的服务可以分为两大类，即主机与从机，主机提供数据，从机负责定期从主机获取最新的数据实现数据同步的目的。即使是复杂的多主的场景中，也可以把服务之间理解为互为主从，这样拆解后，对于`OpenLdap`整体的数据同步配置就比较清晰容易了，只需要关心主机与从机具体的配置即可。

针对常见的配置场景，本人提供了一个在线的[配置生成工具](https://blog.jianggujin.com/c/slapd/)，该工具中可快速对`OpenLdap2.4`、`OpenLdap2.5`的基本信息、主从数据同步等进行配置。配置页面截图如下：
![配置生成工具](/static/img/460a27d9b7ce9d8c9b41bc519715149e.image.webp)

第一部分概述

第一部分概述

第一部分概述

第一部分概述

第一部分概述

1.1 OpenLDAP简介

第一部分 概述

第一部分 概述

第一部分 概述

第一部分 概述

第一部分 概述

1.1 OpenLDAP简介

第一部分概述

第一部分概述

第一部分概述

第一部分概述

第一部分概述