实现用户操作日志分表记录(分库分表——水平切分)

本文介绍了如何通过SpringAOP实现用户操作日志的分表记录,以减轻数据库压力。通过设置状态值status区分正常日志和报警日志,创建新的报警日志实体和服务,并实现分表存储。查询时使用不同接口调用,实现水平切分,降低单一表的数据量,提高系统性能。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

前一段时间同事在写 SpringAOP拦截Controller实现用户操作日志记录(自定义注解的方式)时,把获得的日志和报警日志全部存到了一个数据库表中,我在对这个表进行查询时通过这同一个接口,当数据量过大时,对系统的压力会非常的大,所以在后续的代码中,把这个表进行分表存储查询:

定义一个状态值status,用来存储区分正常日志和报警日志的值

// 返回的status
 	JSONObject jo = (JSONObject) JSONObject.toJSON(jsonResult);
 	String body = jo.getString("body");
 	JSONObject bd = JSONObject.parseObject(body);
 	String status = bd.getString("status");

重新写一个报警日志的实体类、Service,用来存储报警日志,创建Spring AOP切面类时分表记录:

	UserOperateLog uol = new UserOperateLog();
	//新建的存储报警日志的实体类
	UserOperateAlarmLog uoal = new UserOperateAlarmLog();
	// userId不为空
	if(!userId.equals("") && !userId.equals(null)){
   
		// 获取用户名称
		MyworkLeader leader = leaderService.getLeaderByAd(userId);
		//判断当userId不为空时,判断status值进行分表存储
		if(status.equals("true")){
   
			uol.setUserId(userId);
			uol.setOptionName(optionName);
			if(leader!= null){
   
				uol.setUserName(leader.getName());
			}else{
   
			 	uol.setUserName("");
			}
			uol.setOperateDesc(option);
			uol.
### 分库分表的概念 分库分表是一种水平数据库的技术,旨在解决单一数据库实例无法承受大量数据和高并发访问的问题。通过将数据按照一定的规则布到多个物理数据库中,可以有效提升系统的可扩展性和性能。 #### 实现方式 1. **垂直割** - 将不同的业务模块别存放在独立的数据库中,每个数据库负责特定的功能模块。这种方式适合于业务逻辑清晰、模块化程度高的应用系统[^2]。 2. **水平切分(Sharding)** - 根据某些字段(通常是主键或者唯一索引列),把相同结构的数据散存储在多个子或子库中。例如,可以根据用户ID取模来决定记应该保存在哪一个具体的片里[^3]。 3. **混合模式** - 结合上述两种策略的优点,在实际项目开发过程中灵活运用。先按业务领域划成若干个大区,再针对各个区域内进一步实施细粒度上的水平切割操作[^4]。 ### 最佳实践 - **合理规划片键的选择**:选择合适的片键对于提高查询效率至关重要。理想的片键应当具有较高的基数(cardinality),即能均匀地配流量至所有节点之上。 - **保持一致性的机制设计**:当涉及到跨库事务时,需引入布式事务管理器或其他补偿措施以确保最终一致性[^1]。 - **优化读写路径**:为了减轻热点问题带来的压力,可以通过增加只读副本的方式来进行读写离;同时利用缓存技术减少对后台DB的压力。 - **监控与运维自动化建设**:建立完善的日志收集体系以及告警通知流程,及时发现潜在风险并作出响应。此外,借助工具链完成日常维护工作如备份恢复等也是必不可少的一环。 ```sql -- 创建分表语句示例 (基于 MySQL) CREATE TABLE user_0 LIKE user; CREATE TABLE user_1 LIKE user; INSERT INTO user_${userId % 2} VALUES (...); SELECT * FROM user_${userId % 2}; ``` ### 数据库架构中的位置 在整个数据库架构的设计阶段就需要考虑是否采用分库分表方案。创业初期可能只需要简单的单体架构——“一个服务对应一个库”。随着业务的增长和技术栈的发展,逐步演变为更复杂的微服务体系下的多级缓存加后端持久化的组合形式。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值