金融机构多场景关键应用下的存储架构如何设计？

字数 4415阅读 4197评论 0赞 7

# 一、引言
金融机构存在多场景下的关键应用，银行业更多的关注联机交易与总账系统，保险行业则将投保理赔类系统视为关键系统，如何选择适合各场景下的存储，如何设计适合业务的存储架构，显得尤为重要。
#二、当前主流存储架构分析
现有的存储系统经过长期发展，种类及其繁多，架构也各不相同，仅靠一文不可能讲得完全详尽，这里主要针对架构进行相关讨论。
当前主流架构主要分为集中式存储和分布式存储两种。
## 1.集中式存储
集中式存储是基于双控制器或多控制器架构的企业级存储系统，如图1所示：
![](/home/attachment/202210/23/1260435_166653712388906.png)
 图1：集中式存储架构图

按照图1所示，集中式存储的系统架构I/O路径短，具有访问延迟小的优势，此外，还可通过内置BBU电池实现掉电保护，从而保障缓存中的数据在掉电后不丢失，再结合双活、容灾、CDP等技术保障业务系统的连续性和数据安全性。

集中式存储技术成熟，架构简单，有足够的稳定性，对高IOPS、低延时、和数据强一致性有很好支持。所以，集中式存储的特性适合作为金融核心业务系统的数据库存储。

传统存储的系统架构决定了其扩展能力有限，无法很好支撑高并发访问性能。随着数据量不断增长，集中式存储增长空间越来越有限。
## 2.分布式存储
分布式存储是采用分布式架构的存储集群，将数据分布在不同物理位置，并通过网络把它连接起来，如图2所示。与传统的高端服务器、高端存储器和高端处理器不同的是，互联网公司的分布式存储系统由数量众多的、低成本和高性价比的普通 PC 服务器通过网络连接而成，横向扩展能力很强。
![](/home/attachment/202210/23/1260435_166653744359860.png)
图2：分布式存储架构图

按照图2所示，分布式存储有效解决了传统集中式存储的可扩展性问题，规模可扩展至上千个节点，容量扩展到上百PB甚至EB级，性能随容量线性提升。按需在线扩容后，自动实现数据再均衡。分布式存储的多个存储节点能够同时提供读写服务，因此具有很高的吞吐率，可达到几十GB/s。

分布式存储使用多副本和纠删码技术实现数据保护，使用多副本机制，可极大提高存储的高可用性，但是由于多副本机制，导致存储容量有效利用率较低。而纠删码技术，即可提高存储的可用性，相对于副本机制，存储容量有效利用率亦有很大提高，但该模式，存储读写性能较低。

当前主流的分布式存储产品主要有以下几种（仅列举出开源产品）：

- Ceph：适合云平台块存储和对象存储
- HDFS：适用于大数据场景
- Glusterfs：适用视频，音频等大文件和以读为主的场景
- Beegfs/Luster：适用于高性能计算场景

# 三、金融机构业务场景分析与架构选型思路

首先，需明确不同金融机构不同场景下的业务特点，此处，以银行业与保险行业为例，比如：银行业的联机交易业务或核心业务，该类型业务，主要体现在客户层面对于业务响应的快慢，故而对于读写的性能要求极高，此外，对于事务性也有极高的要求，交易业务要求数据必须是强一致的，不允许出现脏读，脏写的情况。

但是，像银行业或保险行业的影像类系统，该类型系统，主要存储的是客户的影像媒体数据，数据多以大文件，非结构化数据为主，业务特点也多以影像数据的查询为主，主要是对性能有较高要求。

针对上述出现的类核心业务系统，可采用传统的集中式存储架构，该类存储架构，高IOPS、低延时、和数据强一致性有很好支持。

对于影像类业务，由于影像数据偏大文件的特点，以个人实践的情况来看，以Glusterfs为代表的分布式存储最为适合该业务，Glusterfs具有高扩展性、高可用性、高性能、可横向扩展等特点，其根据场景不同，可设置不同类型的卷，如：分布式复制卷，分布式条带卷等，以此来达到高性能读写的目的。

## 1.Glusterfs存储应用场景
个人曾针对客户存储影像数据的需求，设计了Glusterfs集群的存储方案，使用分布式复制卷来确保数据的高可用性，并针对这种卷模式，使用iozone与nmon工具，进行同步与异步场景下不同文件大小相关读写性能测试，测试设备信息如表1：

| 服务器型号 | 内存 | CPU | 类型 | 存储大小 | 网络带宽 |
  | --- | --- | --- | --- | --- | --- |
  | 戴尔（DELL） | 64G | 12C | 物理机 | 3TB(HDD)+128G(SSD) | 10G |
  | 戴尔（DELL） | 64G | 12C | 物理机 | 3TB(HDD)+128G(SSD) | 10G |
  | 戴尔（DELL） | 64G | 12C | 物理机 | 3TB(HDD)+128G(SSD) | 10G |

表1：同步读写测试设备数据

### 1.1.Glusterfs集群架构
![](/home/attachment/202210/23/1260435_166653762159728.png)
图3：Glusterfs集群架构
### 1.2.测试用例
| 文件大小 | 命令 |
| --- | --- |
| 4k | ./iozone -s 4k -i 0 -i 1 -w -t 1 -G -F /mnt/t1 |
| 2G | ./iozone -s 2g -i 0 -i 1 -w -t 1 -G -F /mnt/t1 |
| 4G | ./iozone -s 4g -i 0 -i 1 -w -t 1 -G -F /mnt/t1 |
| 8G | ./iozone -s 8g -i 0 -i 1 -w -t 1 -G -F /mnt/t1 |
| 16G | ./iozone -s 16g -i 0 -i 1 -w -t 1 -G -F /mnt/t1 |
表2：同步读写

| 文件大小 | 命令 |
| --- | --- |
| 4k | ./iozone -s 4k -i 0 -i 1 -w -t 1 -D -F /mnt/t1 |
| 2G | ./iozone -s 2g -i 0 -i 1 -w -t 1 -D -F /mnt/t1 |
| 4G | ./iozone -s 4g -i 0 -i 1 -w -t 1 -D -F /mnt/t1 |
| 8G | ./iozone -s 8g -i 0 -i 1 -w -t 1 -D -F /mnt/t1 |
| 16G | ./iozone -s 16g -i 0 -i 1 -w -t 1 -D -F /mnt/t1 |

表3：异步读写
### 1.3.测试结果
在分布式复制卷模式，同/异步写入，读取数据的场景下，发现其对于大文件的读写支持很好，测试结果如表4，表5：

| 用例编号 | 写（平均吞吐量） | 重复写（平均吞吐量） | 读（平均吞吐量） | 重复读（平均吞吐量） |
| --- | --- | --- | --- | --- |
| 4K | 7352.60 KB/sec | 3508.55KB/sec | 6007.30KB/sec | 6379.64KB/sec |
| 2G | 53855.92KB/sec | 59589.48KB/sec | 59170.50KB/sec | 57179.84KB/sec |
| 4G | 58806.86KB/sec | 57990.84KB/sec | 59863.32KB/sec | 56777.48KB/sec |
| 8G | 57767.80KB/sec | 55574.25KB/sec | 57562.49KB/sec | 53913.17KB/sec |
| 16G | 57196.66KB/sec | 58980.97KB/sec | 51425.59KB/sec | 51036.16KB/sec |

表4：同步读写测试数据

| 用例编号 | 写（平均吞吐量） | 重复写（平均吞吐量） | 读（平均吞吐量） | 重复读（平均吞吐量） |
| --- | --- | --- | --- | --- |
| 4K | 121745.45KB/sec | 6700.69KB/sec | 6493.22 KB/sec | 7381.72KB/sec |
| 2G | 21596.56 KB/sec | 22723.56KB/sec | 99259.41KB/sec | 2848802.50KB/sec |
| 4G | 22864.95 KB/sec | 20860.88KB/sec | 93040.98KB/sec | 2735853.50KB/sec |
| 8G | 21247.79 KB/sec | 20742.79KB/sec | 93401.04KB/sec | 88304.33 KB/sec |
| 16G | 20912.14 KB/sec | 20835.54KB/sec | 90287.25KB/sec | 91120.91 KB/sec |

表5：异步读写测试数据

根据表4可看出，Glusterfs存储对于小文件的读写性能支持并不是很好，但是对于大文件来说，读写性能很强，适合视频流媒体等影像文件的读写

根据表5可看出，虽然Glusterfs适合大文件读写，但是异步读写下，并不是文件越大，读写性能越好，反而在笔者的测试环境下，2G大小的文件，读写性能达到最佳。

该测试数据是基于分布式复制卷进行的数据读写，理论上来讲，该模式下相对于分布式条带卷，读写性能要略微差一些，但是由于采用了多副本机制，所以保证了数据的高可用，但随之带来的是存储容量有效利用率较低以及数据查询效率的降低。

另外，值得一提的是，由于测试场景使用的硬盘为HHD，故而相对于纯SSD存储场景下，读写性能要低一些，后期为满足客户高速读写的需求，将硬盘换为SSD，读写性能翻了一倍不止。

所以，在实际场景中，选择分布式存储时，是否采用多副本，副本数量设置多少，采用SSD还是HHD，需要结合具体业务场景来确定。
# 四、结语
综上所述，金融机构业务存储架构在选型时，需充分考虑到业务场景的特点，有针对性的选取适合的存储产品以及架构，不能一味的求新，求变，应以科技为金融服务为宗旨，通过技术，提高金融机构服务的质量和效率。
# 五、参考资料
分布式vs.集中式，存储架构如何选？
http://www.ceh.com.cn/syzx/1482988.shtml

存储

著作权归作者所有

如果觉得我的文章对您有用，请点赞。您的支持将鼓励我继续创作！

添加新评论0 条评论

Ctrl+Enter 发表

匿名评论

金融机构多场景关键应用下的存储架构如何设计？

添加新评论0 条评论

本文隶属于专栏

作者其他文章

相关文章

相关问题

相关资料