好得很程序员自学网

<tfoot draggable='sEl'></tfoot>

Sharding-Proxy分库分表和数据加密使用场景分析

Sharding-Proxy分库分表和数据加密

主要将实际项目中使用shardingshpere-proxy的经历经验,总结分享一下。

使用场景

公司规划研发了两款针对政务新媒体和数字乡村的SaaS平台,作为新的利润增长点。考虑到以后的用户数量和数据数量,决定按照租户(签约客户)进行分库分表。对于一些敏感数据,例如身份证号、手机号等,使用数据库级别的加密解密,不存储明文数据。 考察了网上已有的一些数据库中间件和分库分表解决方案,公司决定使用 Sharding-Proxy 作为分库分表和数据加密的数据库中间件。主要原因是,它对代码的侵入性很小,开发人员也不需要关注它,减少了学习成本,对DBA也很友好。另一方面,ShardingSphere已进入Apache孵化器,它完全开源免费,社区也很活跃,版本迭代也很快。 本次使用的ShardingSphere-5.0

配置文件讲解

server.yaml resources文件夹,conf文件夹下面 主要有注册中心配置、登录连接配置和基础配置

?

1

2

3

4

5

6

7

8

9

10

11

12

mode:

   type: Cluster  # 集群

   repository:

     type: ZooKeeper  # 使用zookeeper

     props:

       namespace: governance_ds 

       server-lists: 192.168 . 1.100 : 2181

       retryIntervalMilliseconds: 50000

       timeToLiveSeconds: 60

       maxRetries: 3

       operationTimeoutMilliseconds: 50000

   overwrite: true

mode.type: Cluster 使用集群配置,单个部署也可以设置为 Cluster ,没影响 mode.repository 配置存储方式,可以选择使用 ZooKeeper mode.overwrite ,配置加载方式,本地配置是否覆盖配置中心配置。true是可覆盖,以本地为准,将本地配置同步到zookeeper;false则以zookeeper为准 下面还有一些基础配置,是否打印SQL等,暂时可都是要默认

config-sharding.yaml resources文件夹,conf文件夹下面 schemaName 数据库连接,数据库名称 dataSources 数据源 rules 规则 !SHARDING 分库分表规则 tables 表 actualDataNodes 实际对于库表 databaseStrategy 分库策略 none 不分库分表 defaultDatabaseStrategy 默认分库策略 defaultTableStrategy 默认分表策略 defaultKeyGenerateStrategy 默认主键策略 shardingAlgorithms 自定义分片算法 keyGenerators 主键生成策略

config-encrypt.yaml resources文件夹,conf文件夹下面 schemaName 数据库连接,数据库名称 dataSources 数据源 rules 规则 !ENCRYPT 数据加密 encryptors 加密策略,可选择AES或MD5,在下面具体字段可选则加密策略 aes_encryptor,aes可以配置加盐 tables 表 columns 字段s id_number 逻辑字段 plainColumn 原字段 cipherColumn 加密字段 encryptorName 加密策略 queryWithCipherColumn 查询时是否使用加密字段

其他

可以下载源码或者下载程序看看,里面的功能,都有配置文件案例,是注释掉的,一款PostgreSQL的,一款MySQL的 目前就使用这2个功能,其他功能暂时没研究,就不多说了 实际使用时,分库分表和数据加密是一起使用的,所以只用了一个配置文件,都放在rules下面 后面我会把我的配置文件贴上去

使用情况

政务新媒体SaaS平台暂时只使用分库分表 数字乡村SaaS平台,使用了分库分表和数据加密 分库分表,主要做了基于租户分库,部分表,又根据某些业务字段做了分表 分表策略,默认分8个表写法algorithm-expression: monitor_record_${media_id % 8} 我们基于租户的哈希进行分库,但对于某些租户,又想指定数据库,这就需要自定义分库分表策略 要求分库支持哈希和指定,写了自定义分库策略类,有一个静态map,解析执行SQL时,先从map里获取,获取不到,则根据哈希获取 数据加密,主要是添加加密字段和对历史数据处理 可以写一个静态方法,对已存在数据进行处理

总结

sharding-proxy对于按照租户分库分表,以及数据加密,是完全支持的,足够我们使用 使用起来很简单,下载最新稳定版安装即可 如果没有自定义分库分表策略要求,只使用已有的策略,那只需要修改配置文件部署即可 如果需要自定义分库分表策略,也不复杂,写好类打包好,放入ext-lib下即可 配置文件部分示例

?

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

61

62

63

64

65

66

67

68

69

70

71

72

73

74

75

76

77

78

79

80

81

82

schemaName: digital_village

dataSources:

   ds:

     url: jdbc:postgresql: //192.168.1.xxx:5432/digital_village?currentSchema=public&serverTimezone=UTC&useSSL=false

     username: postgres

     password: xxxxxx

     connectionTimeoutMilliseconds: 30000

     idleTimeoutMilliseconds: 60000

     maxLifetimeMilliseconds: 1800000

     maxPoolSize: 120

     minPoolSize: 1

   ds_0:

     url: jdbc:postgresql: //192.168.1.xxx:5432/digital_village_0?currentSchema=public&serverTimezone=UTC&useSSL=false

   ds_1:

     url: jdbc:postgresql: //192.168.1.xxx:5432/digital_village_1?currentSchema=public&serverTimezone=UTC&useSSL=false

     password: xxxxx

rules:

   - !SHARDING

     tables:

       # 需要分库的表,根据租户id分库

       cms_basic_info:

         actualDataNodes: ds_${ 0 .. 3 }.cms_basic_info

       cms_column:

         actualDataNodes: ds_${ 0 .. 3 }.cms_column

       cms_content:

         actualDataNodes: ds_${ 0 .. 3 }.cms_content

       cms_content_text:

         actualDataNodes: ds_${ 0 .. 3 }.cms_content_text

       cms_menu_column_bind:

         actualDataNodes: ds_${ 0 .. 3 }.cms_menu_column_bind

       cms_message_board:

         actualDataNodes: ds_${ 0 .. 3 }.cms_message_board

       # 不需要分库分表的表,全部存储在 ds 数据源

       auth_cfg_catalog_data_permission:

         actualDataNodes: ds.auth_cfg_catalog_data_permission

         databaseStrategy:

           none:

       auth_cfg_column_data_permission:

         actualDataNodes: ds.auth_cfg_column_data_permission

         databaseStrategy:

      

     # 默认分库策略

     defaultDatabaseStrategy:

       standard:

         shardingColumn: customer_id  #分库字段

         shardingAlgorithmName:  customer_id_inline #分库规则:

     defaultTableStrategy:

       none:

     # 默认主键策略

     defaultKeyGenerateStrategy:

       column: id

       keyGeneratorName: snowflake

     # 自定义分片算法

     shardingAlgorithms:

       customer_id_inline:

         type: CLASS_BASED

         props:

           strategy: standard

           algorithmClassName: cn.lonsun.dv.DigitalVillageShardingAlgorithm

     # 主键生成策略

     keyGenerators:

       snowflake:

         type: SNOWFLAKE

           worker-id: 123

   - !ENCRYPT

     encryptors:

       aes_encryptor:

         type: AES

           aes-key-value: xxxwwaS213123SAD

       md5_encryptor:

         type: MD5

       party_position:

         columns:

           mobile:

             plainColumn: mobile

             cipherColumn: mobile_cipher

             encryptorName: aes_encryptor

       village_population:

           id_number:

             plainColumn: id_number

             cipherColumn: id_number_cipher

     queryWithCipherColumn: true

到此这篇关于Sharding-Proxy分库分表和数据加密的文章就介绍到这了,更多相关Sharding-Proxy分库分表内容请搜索以前的文章或继续浏览下面的相关文章希望大家以后多多支持!

原文链接:https://blog.csdn.net/u010882234/article/details/124052021

查看更多关于Sharding-Proxy分库分表和数据加密使用场景分析的详细内容...

  阅读:24次