next

往期文章链接目录 文章目录 往期文章链接目录 BERT Recap Overview BERT Specifics There are two steps to the BERT framework: pre-training and fine-tuning Input Output Representations Tasks results Ablation studies Effect of Pre-training Tasks Effect of Model Sizes Replication study of BERT pre training that includes the specific Modifications Training Procedure Analysis RoBERTA tests and results Results 往期文章链接目录 BERT Recap Overview Bert (Bidirectional Encoder Representations from Transformers) uses a “masked language model” to randomly mask some tokens from the input and predict the original vocabulary id of the

简介 oracle体系结构 1. 数据库 Oracle 数据库是数据的物理存储。这就包括（数据文件ORA或者 DBF、控制文件、联机日 志、参数文件）。其实Oracle 数据库的概念和其它数据库不一样，这里的数据库是一个操作系统只有一个库。可以看作是Oracle 就只有一个大数据库。 2. 实例 一个 Oracle 实例（Oracle Instance）有一系列的后台进程（Backguound Processes)和内存结构（Memory Structures)组成。一个数据库可以有 n 个实例。 3. 用户 实例是：用户。不同实例可以建相同名字的用户。 MySQL的实例是：数据库。 4. 表空间 表空间是 Oracle 对物理数据库上相关数据文件（ORA或者 DBF 文件）的逻辑映射。一个数据库在逻辑上被划分成一到若干个表空间，每个表空间包含了在逻辑上相关联的一组结构。每个数据库至少有一个表空间(称之为system表空间)。 每个表空间由同一磁盘上的一个或多个文件组成，这些文件叫数据文件(datafile)。一个数据文件只能属于一个表空间。 5. 数据文件（dbf 、ora ） 数据文件是数据库的物理存储单位。数据库的数据是存储在表空间中的，真正是在某一个 或者多个数据文件中。而一个表空间可以由一个或多个数据文件组成，一个数据文件只能属于一个表空间

1、RESTful发展背景及简介 网络应用程序，分为前端和后端两个部分。当前的发展趋势，就是前端设备层出不穷（手机、平板、桌面电脑、其他专用设备......）。因此，必须有一种统一的机制，方便不同的前端设备与后端进行通信。这导致API构架的流行，甚至出现"APIFirst"的设计思想。RESTful API是目前比较成熟的一套互联网应用程序的API设计理论。 REST（Representational State Transfer）表述性状态转换，REST指的是一组架构约束条件和原则。 如果一个架构符合REST的约束条件和原则，我们就称它为RESTful架构。REST本身并没有创造新的技术、组件或服务，而隐藏在RESTful背后的理念就是使用Web的现有特征和能力， 更好地使用现有Web标准中的一些准则和约束。虽然REST本身受Web技术的影响很深， 但是理论上REST架构风格并不是绑定在HTTP上，只不过目前HTTP是唯一与REST相关的实例。 2、RESTful设计风格 2.1、推荐格式 1）url格式： http(s): // server.com/api-name/{version}/{domain}/{rest-convention} {version}代表api的版本信息。 {domain}是一个你可以用来定义任何技术的区域(例如：安全-允许指定的用户可以访问这个区域。

　　InnoDB 采用了MVCC来支持高并发，并且实现了四个标准的隔离级别。其默认级别是REPEATABLE READ(可重复读) ，并且，通过间隙锁（next-key locking）策略防止幻读的出现。间隙锁使得InnoDB 不仅仅锁定查询涉及的行，还会对索引中的间隙进行锁定，防止幻影行的插入。 　　InnoDB 是基于聚簇索引建立的。InnoDB的索引结构和mysql的其他存储引擎有很大的不同，聚簇索引对主键查询有很高的性能。不过它的二级索引（second index，非主键索引）中必须包含主键列，所以如果主键列很大的话，其他的所有索引都会很大。因此，若表上的索引较多的话，主键应该尽可能的小。INNODB 的存储格式是平台独立的，也就是说可以将数据和索引文件从intel平台复制到power pc或者sun sparc平台。 　　InnoDB 内部做了很多优化，包括从磁盘读取数据时采用的可预测性预读，能够自动在内存中创建hash索引以加速读操作的自适应哈希索引（adaptive hash index），以及能够加速插入操作的插入缓冲区（insert buffer）等。 　　InnoDB 的行为是非常复杂的，不容易理解。如果使用了InnoDB，笔者强烈建议阅读官方手册中的“InnoDB事务模型和锁” 一节。如果应用程序基于InnoDB构建

对于.net core的贡献，我们都是受益人。 HttpContext HttpContext是Http请求到达服务器后被服务器根据接口定义（这个接口定义实际上就是Feature层，由各种Feature转换而来的）转换而成的一个对象，它代表了当前请求的所有内容，它有两个核心的对象，一个是HttpRequest,另一个就是HttpResponse，HttpContext在已注册的各个中间件中传递、加工后形成最终的HttpResponse然后反馈给请求者。一个HttpContext类似于下面这样的结构： public class HttpContext { public HttpRequest Request { get ; } public HttpResponse Response { get ; } } public class HttpRequest { public Uri Url { get ; } public NameValueCollection Headers { get ; } public Stream Body { get ; } } public class HttpResponse { public NameValueCollection Headers { get ; } public Stream Body { get ; } public int

5.9内核已于48分钟前发布： 主要的变更如下（引用自：https://www.phoronix.com/scan.php?page=article&item=linux-59-features&num=2）： Processors / Platforms - FSGSBASE is finally mainlined in offering various performance benefits. - The Intel P-State driver for frequency scaling now supports operating in passive mode with hardware p-states (HWP) enabled. - P2PDMA is now enabled for usage with all AMD Zen CPUs and newer for peer-to-peer direct memory access between multiple PCI Express devices. - Continued POWER10 enablement for these upcoming IBM/OpenPOWER processors. - Improved TLB flushing on OpenRISC. - Intel Keem Bay

作者：raycp 原文来自安全客： https://www.anquanke.com/post/id/197639 漏洞描述 qemu-kvm 默认使用的是 -net nic -net user 的参数，提供了一种用户模式（user-mode）的网络模拟。使用用户模式的网络的客户机可以连通宿主机及外部的网络。用户模式网络是完全由QEMU自身实现的，不依赖于其他的工具（bridge-utils、dnsmasq、iptables等），而且不需要root用户权限。QEMU使用Slirp实现了一整套TCP/IP协议栈，并且使用这个协议栈实现了一套虚拟的NAT网络。SLiRP模块主要模拟了网络应用层协议，其中包括IP协议（v4和v6）、DHCP协议、ARP协议等。 cve-2019-6778这个漏洞存在于QEMU的网络模块SLiRP中。该模块中的 tcp_emu() 函数对端口113( Identification protocol )的数据进行处理时，没有进行有效的数据验证，导致堆溢出。经过构造，可实现以QEMU进程权限执行任意代码。 漏洞复现 首先是安装环境，根据 官方 描述，漏洞版本是 3.1.50 ，但是我在git中没有找到这个版本，于是使用的是 3.1.0 ，使用下面的命令编译qemu。 git clone git://git.qemu-project.org/qemu.git

点击上方 一个优秀的废人 ， 选择 设为星标 优质文章，及时送达 blog.csdn.net/tr1912/article/details/81668423 Mysql 锁类型 一、锁类型介绍： MySQL 有三种锁的级别：页级、表级、行级。 表级锁：开销小，加锁快；不会出现死锁；锁定粒度大，发生锁冲突的概率最高，并发度最低。 行级锁：开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低，并发度也最高。 页面锁：开销和加锁时间界于表锁和行锁之间；会出现死锁；锁定粒度界于表锁和行锁之间，并发度一般 算法： next KeyLocks 锁，同时锁住记录 (数据)，并且锁住记录前面的 Gap Gap 锁，不锁记录，仅仅记录前面的 Gap Recordlock 锁（锁数据，不锁 Gap） 所以其实 Next-KeyLocks=Gap 锁 + Recordlock 锁 二、死锁产生原因和示例 1、产生原因： 所谓死锁 ：是指两个或两个以上的进程在执行过程中，因争夺资源而造成的一种互相等待的现象，若无外力作用，它们都将无法推进下去。此时称系统处于死锁状态或系统产生了死锁，这些永远在互相等待的进程称为死锁进程。表级锁不会产生死锁。所以解决死锁主要还是针对于最常用的 InnoDB。 死锁的关键在于：两个 (或以上) 的 Session 加锁的顺序不一致。 那么对应的解决死锁问题的关键就是