数据库建设方案
读多写少
写多读少
写多读多
数据库集群方案优缺点

读多写少
解决方案：采用传统关系型数据库足以应对，若并发量很大，采用mysql集群即可应对！


写多读少
1、业务场景：滴滴、饭堂刷卡机等，采用传统关系数据库是不适合，因为传统数据库操作涉及事物机制，每次写入操作需要进行undo、redo操作，然后将redo操作记录到日志文件，事物开销是难以承受的



2、解决方案一（针对低价值数据）：

（1）如果低价值数据，可以采用noSQL存储数据

（2）noSQL数据库不做sql语法校验，抛弃了复杂的表结构和约束，因此数据写入速度很快

（3）构建业务系统需要创建两个数据源



3、解决方案二（针对高价值数据）：

（1）采用tokuDB（mysql引擎）存储

（2）tokuDB的写入速度是innoDB的9~20倍

（3）构建业务系统需要创建两个数据源


写多读多
1、微信、QQ，需要存储许多离线消息，并且用户上线还需要读取离线消息，属于读多，写多，传统关系型数据库是难以支撑的

2、解决方案：采用noSQL数据进行存储


数据库集群方案优缺点
1、无论是传统关系型还是noSQL数据库都是支持搭建数据库集群的

2、缺点：读写速度远低于单节点数据库，如创建订单，mycat管理集群，mycat需要生成全局主键，还要判断商品是什么类型，然后进行路由判断存储，正因为这些额外工作，所以读写低于单节点数据库

3、优点：支撑更大的并发量、存储等多的数据；单节点数据库并发量有限（10000左右），且数据量一旦大于2000万，性能将极具降低

问个问题：就是如何避免多人并发时办理同一条数据，这条数据是办理完成后就会消失。而且，当一个人办理时，别人是看不见这条数据的。我运行时，出现了多人同时办理这一条，数据库出现死锁。
回答：
第一  锁机制

第二  脚本里参数化成一条数据只能用一次

第三  程序校验正在update的数据 前台无法在进行操作
 

关于并发操作引起的数据安全和性能问题简单做个总结：
安全问题：
考虑两个方面：数据库锁和java多线程处理
数据库锁：
悲观锁和乐观锁
悲观锁：update行锁，表锁。在修改数据库行的时候利用数据库自身的特性，不让其他事务去操作这张表的这些数据，待提交之后，再执行提交。
乐观锁：默认不会发生事务并发导致数据安全问题。在提交的时候去校验一下版本号（Hibernate可以通过配置控制）或者时间戳。
数据库隔离级别：
脏读 不可重复读幻读
读取未提交 
Y Y Y
读取已提交 
N Y Y
可重现的读取 
N N Y
序列化 
N N N


java多线程：
同步方法或者同步块：synchronized（实例/Class）。原子性，可见性，有序性。
轻量级锁：volatile。可见性和有序性。可以用在boolean或者一些读的场景。
java.lang.concurrent.Lock包。
读写锁：读锁，在读的时候不允许其他线程写操作，但允许读操作；写锁，在写的时候不允许其他线程读写操作。可用于缓存。
private final ReentrantReadWriteLock rwl = new ReentrantReadWriteLock();
	private final Lock r = rwl.readLock();
	private final Lock w = rwl.writeLock();



线程池：所线程并发，可以创建线程池。线程池的作用可以在创建线程和销毁线程上节约性能。
Java通过Executors提供四种线程池，分别为：
newCachedThreadPool创建一个可缓存线程池，如果线程池长度超过处理需要，可灵活回收空闲线程，若无可回收，则新建线程。
newFixedThreadPool 创建一个定长线程池，可控制线程最大并发数，超出的线程会在队列中等待。
newScheduledThreadPool 创建一个定长线程池，支持定时及周期性任务执行。
newSingleThreadExecutor 创建一个单线程化的线程池，它只会用唯一的工作线程来执行任务，保证所有任务按照指定顺序(FIFO, LIFO, 优先级)执行。

集合类线程安全：
用ConcurrentHashMap代替HashMap：采用锁分段技术提高性性能。
ArrayList怎么保证线程安全：
1、synchronized
2、  List<Map<String,Object>> data=Collections.synchronizedList(new ArrayList<Map<String,Object>>());
3、一般情况下，因为性能问题不考虑用Vector代替ArrayList。在使用ArrayList注意下线程安全。

高并发下已有很多解决方案，说一说现公司在并发没太高的实际场景下是怎样控制并发问题的。

首先，采用乐观锁的思想，在校验时间戳或版本中选择了时间戳，基本思想是：每次更新数据都会更新时间戳为当前系统时间，在更新数据前先将本地时间戳与数据库里存的时间戳对比一下，若时间戳一样则证明没人改过，可以进行更新操作，否则不允许更新。从数据库获取数据时会获取到数据的时间戳t1，更新数据时，更新操作分为三步：1、重新查询数据库中的要更新的数据的时间戳t；2、比较t1和t，若相等则继续步骤3，若不相等则说明有别的事务已更新该数据，直接返回更新失败；3、更新数据库。

考虑这样的情况：如果有两个事务A和B同时去更新同一条数据，它们从数据库读取的都是t1，事务A执行到第二步的时候自然时校验通过，但此时在它还没执行第三步的时候事务B也运行到此处，那么事务B也将会校验时间戳通过，后果就是不知道数据库最终诗句是A的还是B的了。解决办法是将步骤1 2 3当成一个原子，执行1之前加锁，执行3后再释放锁，这样事务B在执行步骤1的时候得等待事务A锁的释放，然后查出的时间戳必然不等于t1，校验会失败。这里的加锁可以简单用map就能实现，将数据主键put进去，释放时将其remove即可。