NOSQL（sqlだけでなく）；
非リレーショナルデータベースを指します。これには、拡張が容易で、データ量が多く、パフォーマンスが高く、多様で柔軟なデータモデルがあるという利点があります。
従来のACIDとは何ですか？
原子性：事务里面的操作要么全执行，要么都不执行;
一貫性：事务开始前和结束时，数据库的完整性约束不被破坏。比如A向B转账，不可能A扣了钱，但是B没有收到;
分離：并发执行的事务对彼此的中间状态不可见;
耐久性：事务一旦提交，对数据库的修改就是永久了;
トランザクションの4つの分離レベル
READ UNCOMMITTEDに（読むUNCOMMITED）：会脏读、不可重复读、幻读问题;
【脏读：指的是一个事务读取了另一个事务未提交的数据】
【不可重复读：指的是在一个事务内，多次读取某一行数据，结果不一致】
【幻读：指的是一个事务读取了另一个事务插入的数据，导致前后读取不一致】
（読み取りコミット）コミット読む：一个事务当等另一个事务提交后才能读取数据，会出现不可重复读和幻读问题；（Oracle的默认隔离级别）
反復可能読み取り（反復可能読み取り）：一个事务开启时，不允许其他事务修改该事务的数据，会出现幻读问题；（MySQL的默认隔离级别）
直列化（シリアライズ）：最高的隔离级别，事务串行化执行;
CAP理論？
Consistency：一致性
Availability: 高可用
partition tolerance:分区容错
redisはCPを保証します
redisはシングルスレッドの非ブロッキングIO多重化モデルであり、デフォルトで16個のライブラリーを備えています
シングルスレッド：不要なコンテキストの切り替えと競合状態の消費CPUの回避、
IO多重化：ポーリングを使用して準備されたストリームを順番に処理し、無駄な操作の多くを回避。
一般的に使用されるRedisデータ構造？
1. String: 简单的k-v键值对；
2. Hash：是一个String类型的field和value的映射表，hash特别适合用于存储对象；
3. list:底层实现是双向链表；
4. set：功能与list类似，特殊之处set可以排重；
5. sorted set: 和set相比，增加了一个score参数，使得集合中的元素能够按照score进行有序排列，并且是插入有序的，即自动排序；
redisの永続性？
1.RDB：
在指定的时间间隔内，把内存中的数据集快照写入磁盘，恢复的时候直接将磁盘的数据集写入内存
默认是15分钟1次，5分钟100次，1分钟10000次写操作触发
保存的是dump.rdb文件
利点：适合大规模的数据恢复
欠点：
1 会丢失最后一些快照后的所有修改。;
2 fork子线程时，内存中的数据被克隆的一份，2倍空间的膨胀性需要考虑。;
2.AOF（ファイルのみを追加）：
以日志的形式记录每个写操作，只需追加文件不许改写文件，redis启动之初会读取文件来重新执行命令来构建数据
生成是appendonly.aof文件; 默认是关闭的，开启时 appendonly no 改成yes
書き換え当aof文件超过某个设定的阀值时，redis就会启动文件的压缩，只保留恢复数据的最小指令集，可以使用命令gbrewirteaof执行メカニズム：。
リライトfork一个新线程来重写，先写临时文件再rename，重写时不会读取旧的aof文件，而是把内存中的数据用命令的形式重写一个新的aof文件原則：;
リライトトリガredis会记录上次重写aof文件的大小，默认配置当aof文件是上次重写的一倍且文件大于64M条件：;
rdbとaofの両方を同時に有効にすると、redisは最初にaofファイルをロードして元のデータを復元します。
比較：
1 aof文件比red文件更新频繁，优先使用aof还原数据。;
2 aof比rdb更安全，更大。;
3 aof性能比rdb差。;
4。如果两个都配了，优先加载aof
Redisビジネス？
一个队列中一次性、顺序性、排他性的执行一系列命令，不保证原子性，同一个事务内如果有一条命令执行失败，其他的命令仍然会被执行，没有回滚；
トランザクション関連コマンド：
1.discard：取消事务，放弃执行事务内的所有命令 ;
2.exec：执行事务内的所有命令 ;
3.mutil：标记一个事务的开启 ;
4.watchキー[キー监视一个（或多个）key，如果在事务执行之前，这个key被其他命令所改动，那么事务将被打断...]：;
5.unwatch：取消watch命令对key的监视 ;
watchコマンドは、楽観的ロック、楽観的ロック戦略に似ています。送信されるバージョンは、実行されるレコードの現在のバージョンよりも大きい必要があります。
redisクラスター？
** redisマスター/スレーブレプリケーション：**読み取り/書き込みの分離、災害復旧、
1つのタイプはマスターデータベース（マスター）、1つのタイプはスレーブサーバー（スレーブ）
1 主数据库可以进行读写操作，当发生写操作的时候自动将数据指令集通道到从数据库。;
2 从服务器一般是只读的，一个主库可以有多个从库，一个从库只能有一个主库。;
設定配从不配主：;
ライブラリ設定コマンドから：slaveof 主库Ip 主库端口,查看命令 info replication
原則：
1 slave启动成功后会给master发送一个sync命令。;
2 master收到sync命令个启动后台存盘程序，同时收集所有接收到的用于修改数据的指令集，在后台程序执行完成后，传送整个文件给slave完成一次全量同步。;
3 全量复制：slave接收到数据文件时，将其存盘，并加载到内存。;
4 增量复制：master继续将收集到的新指令集发送给slave。;
5 slave只要重连master，一次全量复制自动执行;
センチネルモード
后台监控主机是否故障，如果故障根据投票数，将slave转换成master（センチネル）：;
Redisのクラスタ
redis3.0之后版本支持redis-cluster集群，采用的是无中心结构，每个节点保存数据和整个集群状态，每个节点和其他所有节点连接クラスタ：。
構造特性：
1 所有的redis彼此互连（ping-pong），内部使用二进制协议优化传输数据和带宽。;
2 节点的fail是通过集群中超过半数的节点检测失效才生效。;
3 客户端与redis节点直连，连接集群中任何一个可用节点即可。;
4 redis集群预分配好16384个slot(槽)所有的节点（不一定平均分配），添加k-v时，对key使用crc16算法得到一个hash，取模16384决定将key放入哪个slot;;
アトミック性を確保するために、複数のコマンドでredisを同時に実行するにはどうすればよいですか
1.使用redis事务；
2.使用redis+lua脚本；
キャッシュとデータベースの二重書き込みの一貫性を確保するにはどうすればよいですか？
1.先更新数据库再更新缓存；
2.如果对数据有强一致性要求，不建议放缓存；
MaxMemory：最大キャッシュ構成。
デフォルトは0で、最大キャッシュは指定されていません。新しいデータが追加され、最大メモリが操作されると、redisがクラッシュするため、設定する必要があります。
redisメモリデータセットが特定のレベルに達すると、データ消去戦略が実装されます。
Redisの有効期限戦略とメモリ消去戦略：
redis过期策略采用的是定期删除+惰性删除
定期的にクリア：redis每隔100ms随机抽样检查，是否有过期的key,有则删除，但是会导致很多过期的key没有删除;
不活性の削除：在获取某个key的时候redis会检查一下key是否过期，过期则删除;
メモリ戦略の6つのアウトがあります。
1.volatile LRU-：从已设置过期时间的数据集中挑选最近最少使用的数据淘汰;
2.volatile-TTL：从已设置过期时间的数据集中挑选将要过期的数据淘汰;
3.volatile-ランダム：从已设置过期时间的数据集中随机挑选数据淘汰;
LRU-を4.allkeys：当内存不足以容纳新写入数据时，在键空间中移除最近最少使用的key（这个是最常用的）;
5.allkeys-ランダム：当内存空间不足以容纳新写入的数据时，随机淘汰数据;
6.No-立ち退き：禁止驱逐数据，当内存不足以容纳新写入的数据时报错。
redisの一般的なパフォーマンスの問題？
master最好不要做任何持久化工作，如rdb内存快照和aof日志文件，如果数据比较重要，某个slave开启aof备份数据，策略设置为每秒同步一次;master和slave最好在同一个局域网；尽量避免压力很大的主库上增加从库，不要用图状结构，用单向链表结构更为稳定。即： Master <- Slave1 <- Slave2 <-Slave3…
スパイクシステムのセットアップ方法 高い同時実行性はどうなりますか？
アーキテクチャ設計：
1.システムの上流でリクエストをインターセプトし、下流の圧力を軽減します。
秒杀系统特点是高并发，但实际秒杀成功的请求数量却很少，所以不在前端拦截可能造成数据库读写锁冲突，甚至导致死锁，最终请求超时。
2.テイク利点利用缓存可以极大的提高系统读写速度キャッシング：。
3.メッセージング消息队列可以削峰，拦截大量并发请求ミドルウェア：。
フロントエンド設計スキーム：
1.ページの静的：将活动页面上的所有可静态元素全部静态化;
2.繰り返し送信は禁止されています：用户提交之后按钮置灰;
3.ユーザーの現在の制限：在某一时间段内，只允许用户提交一次请求;
バックエンド設計計画：
1 网关限制uid访问频率。;
2 服务层：采用消息队列缓存请求和利用缓存应对请求。;
3 把减库存和生成订单逻辑使用mysql存储过程实现，减少事务锁持有时间，避免GC和IO的延迟。;
