Java数据库开发笔记

最新推荐文章于 2022-06-02 16:30:11 发布

p@ssword

最新推荐文章于 2022-06-02 16:30:11 发布

阅读量327

点赞数

分类专栏：笔记

本文链接：https://blog.csdn.net/weixin_42154825/article/details/89063958

版权

笔记专栏收录该内容

6 篇文章 0 订阅

订阅专栏

数据库优化
是相对的，主要是查询
语句优化：尽量不使用多表查询（子查询代替，折中方案，如果数据量太庞大也优化不了）、频繁的统计查询。
表使用了索引就不能频繁修改，例如删除，对数据进行逻辑删除不能物理删除，物理删除会频繁的创建新的索引
时间换空间，空间换时间
垂直拆库（接口支持）
水平拆分
保证强大的查询功能，分词处理（类似搜索引擎）
NoSQL(非关系型数据库)使用场景
NoSQL实现了文档存储如JSON、BSON，缓存存储，图像缓存图像搜索
经常要显示的数据整理到文档型数据库如MongoDB
缓存型：Redis（每秒近十万次读写，保存在磁盘，断电后数据能保存）。购物车、短信验证码
分布式数据库
集群是物理形态，分布式是工作方式。
只要是一堆机器，就可以叫集群，他们是不是一起协作着干活，这个谁也不知道；一个程序或系统，只要运行在不同的机器上，就可以叫分布式，C/S架构也可以叫分布式。
术语 RPC（Remote Procedure Call）远程过程调用，通过RPC技术分离业务端,如图所示
严格讲不存在分布式数据库，web服务器通过数据库地址找到数据库服务器本身就是分布式

解决用户访问
Nginx反向代理服务器
正向代理最大的特点是客户端非常明确要访问的服务器地址,服务器只清楚请求来自哪个代理服务器，而不清楚来自哪个具体的客户端；正向代理模式屏蔽或者隐藏了真实客户端信息。

某一业务高并发

多个客户端给服务器发送的请求，Nginx服务器接收到之后，按照一定的规则分发给了后端的业务处理服务器进行处理了。此时请求的来源是客户端，但是请求具体由哪台服务器处理的并不明确，Nginx扮演的就是一个反向代理角色。
客户端是无感知代理的存在的，反向代理对外都是透明的，访问者并不知道自己访问的是一个代理。因为客户端不需要任何配置就可以访问。反向代理隐藏了服务器的信息。

SQL代理
数据库设计
数据量不大时正确设计思想都可以正常发挥
普通

最坑的设计：编程语言+存储过程
可控性不好，所有的处理放在存储过程里完成（适合简单的、吞吐量不大的单数据库实例）

优化方式：降级
处理单一业务，完成后再恢复

恢复

拆库拆表（库表分离）：
一个数据库对应一个业务的思想
拆后关联关系无效，事物也难做
水平拆分：把一个表拆成10个表分开放数据库，每个表存10%数据
垂直拆分：表字段拆分成多张表放多个数据库
5. 缓存
系统是把硬盘磁盘（二进制）数据读取到内存，读写需要时间，延迟加载时间高
解决：
静态文件存（xml、json、）读取更快
内存缓存要考虑数据失效问题。组件：oscache（jsp页面）、ehcache（框架中的mybatis，hibernate，shiro安全框架）
缓存数据库如Redis（noSQL数据库）
6. 缓存与数据库同步
缓存与数据库一定不可能同步
同步处理缓存更慢
使用缓存减少对数据库操作

是否是数据库专用缓存，如ehcache
缓存是否是进行分布式或反向代理操作是使用，Nginx反向代理purge模块
是否采用了缓存数据库，如Redis保存高并发的数据信息统计

乐观锁与悲观锁
悲观锁（建议使用）：数据库自身的机制，事物隔离，当一个session操作某条数据库时，其他session是无法操作的
select * from tablename for update
表示使用了悲观锁，在事物提交或回滚前该数据不允许更新
乐观锁：表里面增加字段（版本号），第一个session修改了该条数据版本号+1；另一个session再去更新发现版本号不对，则不允许更新
数据缓存
所有CPU能处理的数据都要加载到内存中
电脑使用一段时间变慢，因为磁盘存的东西越来越多，寻址时间变长，磁盘碎片增加，花费的寻址时间更长

缓存的思考：
哪些数据需要缓存
不用的数据什么时候清理
_{JVM有处理机制。常用的算法：LRU长时间未使用，FIFO先进先出}
是否需要同步
分布式缓存
_{缓存数据采只读模式，不进行更新处理}
缓存实现：
文件缓存
内存缓存：OSCache（web的jsp）和EHCache（框架上Mybatis，Hibernate，Shiro）
缓存数据库：Redis

缓存机器使用处理负载均衡的Nginx反向代理
缓存数据库Redis集群，可能会导致缓存数据丢失问题
分布式数据库开发就用Redis
9. 数据库更新监听
检测数据更新，触发器只能在数据库层次上出现，触发器会调用过程处理，在分布式中不可取。
另一个误区：定期检测数据库，数据库性能降低
优化：交给程序业务代理处理
在这里插入图片描述
11. 数据库连接池实现原理
连接池：本质是Connection对象数组，存在上下限的。
map实现连接池：所有连接对象被map集合管理，但map集合受到最大连接数控制。如果没有可用连接开辟新的。如果连接满了，追加一个等待唤醒的机制，线程的等待与唤醒机制。使用完后关闭，不是彻底的关闭数据库连接而是将这个连接的可用性重新放回连接池（设置标记true，无连接。false有连接）
做连接池实现最好用Class ConcurrentHashMap<K,V>的实现子类，因为这个类考虑了并发，同步处理。

同步交互：指发送一个请求,需要等待返回,然后才能够发送下一个请求，有个等待过程；
发出一个功能调用时，在没有得到结果之前，该调用就不返回或继续执行后续操作。对象间的协作
异步交互：指发送一个请求,不需要等待返回,随时可以再发送下一个请求，即不需要等待。完成后回调函数，当被调用者执行完成后，会调用调用者提供的回调函数。
区别：一个需要等待，一个不需要等待，在部分情况下，我们的项目开发中都会优先选择不需要等待的异步交互方式。

数据库事务控制
一个有限的数据库操作序列就是一个事物
ACID原则，数据库事物正确执行的四个基本要素的缩写即原子性、一致性、隔离性、持久性。一个支持事务（Transaction）的数据库，必须要具有这四种特性，否则在事务过程（Transaction processing）当中无法保证数据的正确性。
Oracle的事物处理操作
事物处理的核心：要么一起成功要么一起失败
原子性（Atomicity）事务中的操作要么都发生，要么都不发生，不能停滞某个中间环节，事物执行过程中发生错误会回滚，像没发生过一样

A： 800 - 200 = 600
B: 200 + 200 = 400

一致性（Consistency）事务完成后，符合逻辑运算
操作前：A： 800 B：200
操作后：A： 600 B：400

隔离性（Isolation）多个事务并发执行时，一个事务的执行不应影响其他事务的执行

持久性（Durability）已被提交的事务对数据库的修改应该永久保存在数据库中

实际开发中事务处理模式有三种：
jdbc原始处理：commit();rollback();setAutoCommit()
框架中容器控制事物：jta组件
spring事物控制：对jdbc增强。

数据源
DataSource：不重复进行打开关闭数据库，控制连接人数的做法。主要解决数据库频繁打开、关闭带来的数据库性能损耗
数据源配置：容器配置（Tomcat、WebLogic等）、程序配置（spring用c3p0）。
程序配置又分两种：旧的数据库连接池处理、阿里巴巴的druid（可监控操作）
随机取得数据库数据
random随机取