这是一个创建于 1666 天前的主题，其中的信息可能已经有所发展或是发生改变。
场景如下:
SpringCloud 全套, 数据库未分库,主从读写分离;
网关进来根据 api 进 微信微服务 手机 app 微服务, 后台微服务 等, 由这些微服务调用底层的 订单微服务 会员微服务等来完成业务逻辑或者组装数据;
现在后台微服务中的导出会员接口没有控制条数, 一下导出 30w+的会员数据(每个会员还要统计订单情况等), 导致会员微服务挂掉, 进而导致微信微服务无法获取会员信息,无法完成业务(业务要求可用性较高)
我的疑问是: 底层的订单微服务 会员微服务等 是否应该拆成两个, 一个给业务使用, 一个给后台管理系统使用, 且部署分开. 现在比如会员微服务下 MemberController 里面就既有后台增删改查的 又有业务上比如支付时扣减用户余额的, 是否拆开好一点(再次强调:业务要求可用性较高!)?求解答, 谢谢!
SpringCloud 全套, 数据库未分库,主从读写分离;
网关进来根据 api 进 微信微服务 手机 app 微服务, 后台微服务 等, 由这些微服务调用底层的 订单微服务 会员微服务等来完成业务逻辑或者组装数据;
现在后台微服务中的导出会员接口没有控制条数, 一下导出 30w+的会员数据(每个会员还要统计订单情况等), 导致会员微服务挂掉, 进而导致微信微服务无法获取会员信息,无法完成业务(业务要求可用性较高)
我的疑问是: 底层的订单微服务 会员微服务等 是否应该拆成两个, 一个给业务使用, 一个给后台管理系统使用, 且部署分开. 现在比如会员微服务下 MemberController 里面就既有后台增删改查的 又有业务上比如支付时扣减用户余额的, 是否拆开好一点(再次强调:业务要求可用性较高!)?求解答, 谢谢!
 |
1
snappyone 2020-06-01 20:17:47 +08:00 via Android
30 万分成每次 1000 条就好了
|
 |
2
matrix67 2020-06-01 20:18:47 +08:00
分页
|
 |
4
optional 2020-06-01 20:26:13 +08:00
再加一台 slave 为后台专用。
|
 |
6
levelworm 2020-06-01 20:36:33 +08:00 via Android
说分页的未必合乎后台业务需求啊，有时候后台的确需要批量处理，你分页是方便你自己了，但是后台就得写脚本自己抓数据了。对我就这么干过。最好还是分开来，后台专门有台机器。
|
 |
7
Jooooooooo 2020-06-01 20:38:39 +08:00
拆分数据库, 实时交易库和导出类的库分开
然后再去优化业务 |
 |
8
857681664 2020-06-01 20:39:52 +08:00 via Android
导出可以异步放消息队列里，用独立服务处理，我的想法是这样
|
 |
9
leaderhyh OP @Jooooooooo 目前数据库不是痛点且架构师不想动数据库
|
 |
10
CoderGeek 2020-06-01 20:54:20 +08:00
运营与对外分离
|
 |
11
night98 2020-06-01 20:55:10 +08:00
可以起两个服务，但是可以使用分批写入的方式，一次读取一千条左右，写到文件中，参考 http://poi.apache.org/components/spreadsheet/how-to.html#sxssf
如果说内存足够的话，只是说数据库容易被拖死的话，可以单独起一个从库专门用于后台管理系统的导出，然后使用 mysql 自带的 sql 导出到硬盘目录，再用服务器转移到对象存储等文件服务上面 |
|
12
Jooooooooo 2020-06-01 22:01:16 +08:00
@leaderhyh 不是动架构. 只需要多一个从库然后导出专门连这个从库就行.
|
 |
13
yeqizhang 2020-06-01 22:11:41 +08:00
数据库倒不用分离吧，毕竟后台系统不就是操作对外的一些数据。
不针对你现在的问题来说，系统也最好分开两个系统部署不同的机器，这是前期规划没做好呀！ |
 |
14
arrow8899 2020-06-01 22:43:19 +08:00
你这里的导出可以看做是一种报表业务吧，每次导出再去计算成本太大了。通常的做法是用流式处理框架 Flink,Strom 等实时汇总，把计算成本分摊到每一次业务处理上，导出的时候直接读取就行。
|
 |
15
namelosw 2020-06-01 23:05:58 +08:00  1
微服务挂掉，不用 SQL 全读到内存计算了？那假如你是因为内存计算卡死的话
0. 看看能不能把内存计算变成 SQL query，如果不能看下面 0. 看看能不能改成异步 Job，如果不能看下面 1. 最简单的建议单独分微服务出去 2. 如果分出去微服务接着发现数据库也是瓶颈，把数据库用 CDC 之类的弄一个同步，只用来做查询 3. 再不行就 Flint 或者 Spark，这些是大量内存计算的正规军 |
|
16
leaderhyh OP @Jooooooooo 这个已经做了
|
 |
20
wangyzj 2020-06-01 23:57:47 +08:00
微服务挂掉？
内存炸了？ 少量多次吧 |
 |
21
neptuno 2020-06-01 23:59:53 +08:00 via Android
搞个从库
|
 |
22
coderabbit 2020-06-02 01:06:53 +08:00 via Android
我 mysql 实时同步 mongo.50 万数据 20 秒左右导出。一点不拖累服务！
|
 |
25
xuanbg 2020-06-02 08:39:18 +08:00
可以按导出需求做个小小的数仓，然后从数仓导出数据就不会影响到业务，而且导出速度也能提升到毫秒级。
|
 |
26
ytmsdy 2020-06-02 10:19:15 +08:00 1
一次性导出 30w+的会员数量这个操作，应该是规避的高风险操作吧。
毕竟一次性导出这么多数据，除了拿出去卖，我想不到还有什么场景会用到这么多数据。 |
 |
27
arthas2234 2020-06-02 10:42:59 +08:00
你如果是需要频繁导出的话，最好单独做一张表用来保存这些数据，到时候直接查出来就行了
|
 |
28
zoharSoul 2020-06-02 11:25:03 +08:00
会员微服务挂掉 是什么意思?
内存溢出了? |
 |
29
EastLord 2020-06-02 13:58:18 +08:00
流式下载不行吗
|
Select Language