博客

SQL标准定义了4类隔离级别，包括了一些具体规则，用来限定事务内外的哪些改变是可见的，哪些是不可见的。低级别的隔离级一般支持更高的并发处理，并拥有更低的系统开销。

Read Uncommitted（读取未提交内容）

在该隔离级别，所有事务都可以看到其他未提交事务的执行结果。本隔离级别很少用于实际应用，因为它的性能也不比其他级别好多少。读取未提交的数据，也被称之为脏读（Dirty Read）。

Read Committed（读取提交内容）

这是大多数数据库系统的默认隔离级别（但不是MySQL默认的）。它满足了隔离的简单定义：一个事务只能看见已经提交事务所做的改变。这种隔离级别 也支持所谓的不可重复读（Nonrepeatable Read），因为同一事务的其他实例在该实例处理其间可能会有新的commit，所以同一select可能返回不同结果。

Repeatable Read（可重读）

这是MySQL的默认事务隔离级别，它确保同一事务的多个实例在并发读取数据时，会看到同样的数据行。不过理论上，这会导致另一个棘手的问题：幻读 （Phantom Read）。简单的说，幻读指当用户读取某一范围的数据行时，另一个事务又在该范围内插入了新行，当用户再读取该范围的数据行时，会发现有新的“幻影” 行。InnoDB和Falcon存储引擎通过多版本并发控制（MVCC，Multiversion Concurrency Control）机制解决了该问题。

Serializable（可串行化）

这是最高的隔离级别，它通过强制事务排序，使之不可能相互冲突，从而解决幻读问题。简言之，它是在每个读的数据行上加上共享锁。在这个级别，可能导致大量的超时现象和锁竞争。

出现问题

这四种隔离级别采取不同的锁类型来实现，若读取的是同一个数据的话，就容易发生问题。例如：

脏读(Drity Read)：某个事务已更新一份数据，另一个事务在此时读取了同一份数据，由于某些原因，前一个RollBack了操作，则后一个事务所读取的数据就会是不正确的。

不可重复读(Non-repeatable read):在一个事务的两次查询之中数据不一致，这可能是两次查询过程中间插入了一个事务更新的原有的数据。

幻读(Phantom Read):在一个事务的两次查询中数据笔数不一致，例如有一个事务查询了几列(Row)数据，而另一个事务却在此时插入了新的几列数据，先前的事务在接下来的查询中，就会发现有几列数据是它先前所没有的。

在MySQL中，实现了这四种隔离级别，分别有可能产生问题如下所示：

MySQL8 之前使用如下命令查看 MySQL 隔离级别：

SELECT @@GLOBAL.tx_isolation, @@tx_isolation;

MySQL8 开始，通过如下命令查看 MySQL 默认隔离级别：

SELECT @@GLOBAL.transaction_isolation, @@transaction_isolation;

下面是官方文档的说法：

The following list describes how MySQL supports the different transaction levels. The list goes from the most commonly used level to the least used.

•  REPEATABLE READ This is the default isolation level for InnoDB. Consistent reads within the same transaction read the snapshot established by the first read. This means that if you issue several plain (nonlocking) SELECT statements within the same transaction, theseSELECT statements are consistent also with respect to each other. See Section 15.7.2.3, “Consistent Nonlocking Reads”. For locking reads (SELECT with FOR UPDATE or FOR SHARE), UPDATE, and DELETEstatements, locking depends on whether the statement uses a unique index with a unique search condition, or a range-type search condition.
  • For a unique index with a unique search condition, InnoDB locks only the index record found, not the gap before it.
  • For other search conditions, InnoDB locks the index range scanned, using gap locksor next-key locks to block insertions by other sessions into the gaps covered by the range. For information about gap locks and next-key locks, see Section 15.7.1, “InnoDB Locking”.

•  READ COMMITTED Each consistent read, even within the same transaction, sets and reads its own fresh snapshot. For information about consistent reads, see Section 15.7.2.3, “Consistent Nonlocking Reads”.For locking reads (SELECT with FOR UPDATE or FOR SHARE), UPDATE statements, and DELETE statements, InnoDB locks only index records, not the gaps before them, and thus permits the free insertion of new records next to locked records. Gap locking is only used for foreign-key constraint checking and duplicate-key checking.Because gap locking is disabled, phantom row problems may occur, as other sessions can insert new rows into the gaps. For information about phantom rows, seeSection 15.7.4, “Phantom Rows”.Only row-based binary logging is supported with the READ COMMITTED isolation level. If you use READ COMMITTED with binlog_format=MIXED, the server automatically uses row-based logging.Using READ COMMITTED has additional effects:
  • For UPDATE or DELETE statements, InnoDB holds locks only for rows that it updates or deletes. Record locks for nonmatching rows are released after MySQL has evaluated the WHERE condition. This greatly reduces the probability of deadlocks, but they can still happen.
  • For UPDATE statements, if a row is already locked, InnoDB performs a “semi-consistent” read, returning the latest committed version to MySQL so that MySQL can determine whether the row matches the WHERE condition of the UPDATE. If the row matches (must be updated), MySQL reads the row again and this time InnoDBeither locks it or waits for a lock on it.

The READ COMMITTED isolation level can be set at startup or changed at runtime. At runtime, it can be set globally for all sessions, or individually per session.

•  READ UNCOMMITTED SELECT statements are performed in a nonlocking fashion, but a possible earlier version of a row might be used. Thus, using this isolation level, such reads are not consistent. This is also called a dirty read. Otherwise, this isolation level works like READ COMMITTED.

•  SERIALIZABLE This level is like REPEATABLE READ, but InnoDB implicitly converts all plain SELECT statements to SELECT ... FOR SHARE if autocommit is disabled. If autocommit is enabled, the SELECT is its own transaction. It therefore is known to be read only and can be serialized if performed as a consistent (nonlocking) read and need not block for other transactions. (To force a plain SELECT to block if other transactions have modified the selected rows, disable autocommit.)

1. 单例：每个类只允许存在一个的对象，如果延迟初始化需要考虑多线程并发出现的问题，还需要考虑未用volatile时对象为空的情况。
2. 简单工厂：某类不能直接使用构造函数构造，而是需要在另一个类中调用static静态方法构造。
3. 工厂方法：同上，但是方法不是static的了，要先实例化一个对象再在对象中调用。
4. 抽象工厂：不是很记得了，只记得对象家族，建议多复习。（大致为创建出来的抽象对象为很多其他对象的工厂。）
5. 生成器：不是直接构造对象，而是允许一步步的构建对象，例如StringBuilder类。
6. 原型模式：prototype，大致为能以某个对象为原型复制一份一样的，例如clone()方法。

1. 责任链：将能处理问题的对象组成一个链表，问题在链表中迭代查询直到遇见能处理的为止。
2. 命令：将想要运行的命令变成一个对象而不是及时运行，交给其他的对象到该运行时再运行，例如Runnable啥的。
3. 解释器：将语言解释为逻辑上的步骤并且可以自由组合，不是特别记得了（为语言创建解释器，通常由语言的语法和语法分析来定义。）
4. 迭代器：可以迭代集合中的元素而不用去管其实现细节，hasNext和next。
5. 中介者：很多对象相互直接都有关系，而中介者直接充当中介建立他们之间的相互关系。
6. 备忘录：储存一份对象的备忘，例如具体数据和细节防止丢失。例如Serialize。
7. 状态：内在状态变化而发生了好像类发生了变化一样。
8. 策略：类似于spring的IoC，将核心部分留出来交给其他的类来实现，例如Comparator。
9. 模版方法：有个算法模版，而对于不同的对象运行不同的算法细节，例如sort()。
10. 访问者：不是很懂，好像是能动态的给每个访问者增加方法。

1. 适配器：屏蔽上层的细节，为使用者提供统一的接口，例如很多SQL组件。
2. 桥接：不记得了。（将抽象与实现分离开来，使它们可以独立变化。）
3. 组合：在新的类中组合多个别的对象形成新的功能。树形结构，通过操作一个对象来操作一组对象。
4. 装饰：通过继承对类的功能进行拓展。
5. 外观：将很多细节方法统一为一个方法，方便使用。
6. 享元：共享一些细粒度的对象。
7. 代理：反射，不记得了。（控制对其他对象的访问。）

过滤器模式（Filter Pattern）或标准模式（Criteria Pattern）是一种设计模式，这种模式允许开发人员使用不同的标准来过滤一组对象，通过逻辑运算以解耦的方式把它们连接起来。这种类型的设计模式属于结构型模式，它结合多个标准来获得单一标准。

SYN洪泛攻击发生在OSI第四层，这种方式利用TCP协议的特性，发生在三次握手建立TCP连接的过程中。

1.具体过程

• 攻击者发送TCP的SYN，服务器返回ACK后，该攻击者就不对其进行确认，那么这个TCP连接处于挂起状态，所谓的半连接状态。
• 服务器收不到再确认的话，还会重复发送ACK给攻击者，这样就更加浪费服务器资源。
• 攻击者如果发送非常大量的这种TCP连接，由于每一个都无法完成三次握手，所以服务器上这些TCP连接会因为挂起状态而消耗CPU和内存，最后服务器可能死机，就无法为正常用户提供服务。

2.解决方法（SYN cookie）

• 当服务器接收到一个SYN报文段时，其并不知道该报文段来自一个合法用户还是要进行SYN洪泛攻击的攻击者，因此服务器不会为该报文段生成一个半开的连接 ，相反服务器会生成一个初始序列号，该序列号是一个复杂函数（散列函数，由SYN报文段的源IP地址和目的IP地址，源端口号和目的端口号以及仅有服务器知道的秘密数构成），这个初始序列号被称为cookie。服务器会发送这种具有特殊初始序列号的SYNACK报文段，且服务器并不记录该cookie以及其他任何关于SYN的状态信息。
• 如果客户是合法的，则它将返回一个ACK报文段，当服务器收到ACK报文段后，需要验证ACK是否与前面发送的某个SYN相对应。由于服务器没有记录SYN报文段的相关信息，所以其会使用SYNACK报文段的源IP地址和目的IP地址，源端口号和目的端口号以及仅有服务器知道的秘密数生成一个散列函数。如果这个函数的结果（cookie值）加1和客户ACK报文段中的确认值相同，那么服务器会认为该ACK对应于较早的SYN报文段，则其合法，因此服务器会生成一个套接字的全开连接。
• 如果客户没有返回一个ACK报文段，则说明之前的SYN报文段属于要进行SYN洪泛攻击的攻击者，但其并没有对服务器造成任何危害，因为服务器没有为它分配任何资源。

1. 原子性（Atomicity）

事务被视为不可分割的最小单元，事务的所有操作要么全部提交成功，要么全部失败回滚。

回滚可以用回滚日志（Undo Log）来实现，回滚日志记录着事务所执行的修改操作，在回滚时反向执行这些修改操作即可。

2. 一致性（Consistency）

数据库在事务执行前后都保持一致性状态。在一致性状态下，所有事务对同一个数据的读取结果都是相同的。

3. 隔离性（Isolation）

一个事务所做的修改在最终提交以前，对其它事务是不可见的。

4. 持久性（Durability）

一旦事务提交，则其所做的修改将会永远保存到数据库中。即使系统发生崩溃，事务执行的结果也不能丢失。

系统发生崩溃可以用重做日志（Redo Log）进行恢复，从而实现持久性。与回滚日志记录数据的逻辑修改不同，重做日志记录的是数据页的物理修改。

Atomicity

The atomicity aspect of the ACID model mainly involves InnoDBtransactions. Related MySQL features include:

• The autocommit setting.
• The COMMIT statement.
• The ROLLBACK statement.

Consistency

The consistency aspect of the ACID model mainly involves internal InnoDBprocessing to protect data from crashes. Related MySQL features include:

• The InnoDB doublewrite buffer. See Section 15.6.4, “Doublewrite Buffer”.
• InnoDB crash recovery. See InnoDB Crash Recovery.

Isolation

The isolation aspect of the ACID model mainly involves InnoDBtransactions, in particular the isolation level that applies to each transaction. Related MySQL features include:

• The autocommit setting.
• Transaction isolation levels and the SET TRANSACTION statement. See Section 15.7.2.1, “Transaction Isolation Levels”.
• The low-level details of InnoDB locking. Details can be viewed in the INFORMATION_SCHEMA tables (see Section 15.15.2, “InnoDB INFORMATION_SCHEMA Transaction and Locking Information”) and Performance Schema data_locks and data_lock_waits tables.

Durability

The durability aspect of the ACID model involves MySQL software features interacting with your particular hardware configuration. Because of the many possibilities depending on the capabilities of your CPU, network, and storage devices, this aspect is the most complicated to provide concrete guidelines for. (And those guidelines might take the form of “buy new hardware”.) Related MySQL features include:

• The InnoDB doublewrite buffer. See Section 15.6.4, “Doublewrite Buffer”.
• The innodb_flush_log_at_trx_commit variable.
• The sync_binlog variable.
• The innodb_file_per_table variable.
• The write buffer in a storage device, such as a disk drive, SSD, or RAID array.
• A battery-backed cache in a storage device.
• The operating system used to run MySQL, in particular its support for the fsync() system call.
• An uninterruptible power supply (UPS) protecting the electrical power to all computer servers and storage devices that run MySQL servers and store MySQL data.
• Your backup strategy, such as frequency and types of backups, and backup retention periods.
• For distributed or hosted data applications, the particular characteristics of the data centers where the hardware for the MySQL servers is located, and network connections between the data centers.

一个优化过的求所有出栈排列的函数。

        public static void GetAllStackArrangement(int[] array, int index, int[] ans,  int ansIndex, int stackIndex)
        {
            if (index >= array.Length && stackIndex >= ans.Length)
            {
                Console.WriteLine(string.Join(", ", ans));
                return;
            }
            if(stackIndex >= ans.Length)
            {
                int temp = ans[ans.Length - 1];
                ans[ans.Length - 1] = array[index++];
                GetAllStackArrangement(array, index, ans, ansIndex, ans.Length - 1);
                ans[ans.Length - 1] = temp;
            }
            else if(index >= array.Length)
            {
                int temp = ans[ansIndex], temp2 = ans[stackIndex];
                ans[ansIndex++] = ans[stackIndex++];
                GetAllStackArrangement(array, index, ans, ansIndex, stackIndex);
                ans[ansIndex - 1] = temp;
                ans[stackIndex - 1] = temp2;
            }
            else
            {
                int temp = ans[ansIndex] , temp2 = ans[stackIndex];
                ans[ansIndex++] = ans[stackIndex++];
                GetAllStackArrangement(array, index, ans, ansIndex, stackIndex);
                ansIndex--; stackIndex--;
                ans[ansIndex] = temp; ans[stackIndex] = temp2;
                temp = ans[--stackIndex];
                ans[stackIndex] = array[index++];
                GetAllStackArrangement(array, index, ans, ansIndex, stackIndex);
                ans[stackIndex] = temp;
            }
        }

B站上看了蛮多就业向的视频，有时候就在想，假如我一年后没考上研怎么办？
现在这迷惑专业，没有几门课将我们培养到了就业的水准，
看了大公司的面试难度，甚至连面试水平都达不到，
除了本身是个985，似乎丝毫没有竞争力。
虽然说可以自学，但是有太多课程占用了自己的时间。
难道本科教育的目的都是要搞科研吗，还是我们专业的培养方案有问题？
羡慕中南有些专业，有着就业向的课程和有就业经验的老师。
除了考研，也许真的只能搬砖了。。。

不过，无论如何，编程绝对不能放弃，加油！