我们在Mysql中存字段的时候，比如，一些与金钱有关的数据。这个时候就会对精确到的要求非常高。那么这个时候，就会发现我们之前所学的八大基本类型不再能够满足需求，无论是整形还是浮点型，有人会说存整形有什么不可，但是你要知道不是每个人的金额都是整数的；这样不行的话，存浮点型的就可以了嘛，对于银行存钱来说，一个小数点的问题都会将一笔钱的金额变得很大或者很小......So，这个时候你可以尝试一下Decimal类型，你会发现能够很好地解决你的问题。 decimal详细介绍： decimal(a,b) 参数说明： a:指定小数点左边和右边可以存储的十进制数字的最大个数，最大精度为38. b:指定小数点右边可以存储的十进制数字的最大个数。小数位数必须是从0~a之间的值，默认小数位数是0. 举例说明，11615.23653234568这个数存你说的三个格式 decimal：11615 decimal(3)：999 decdimal(3,2)：9.99 decimal(10,5)11615.23653 超出精度范围的数会被强制进位并只显示数据类型定义的格式 备注： decimal数据类型用于要求非常高的精确计算中，这些类型允许指定数值的精确度和计算方法作为选择参数。精确度在这里指为这个值保存的有效数字的总个数。而计数方法指的是小数点后数字的个数。例如：decimal(5,2)规定了存储的值将不会超过五位数字 ，而且小数点后面有两位数字。 实例1： mysql> create table t1(c1 float(10,2), c3decimal(10,2)); Query OK, 0 rows affected (0.02 sec) mysql> insert into t1 values(9876543.21, 9876543.12); Query OK, 1 row affected (0.00 sec) mysql> select * from t1; +------------+------------+ | c1 | c3 | +------------+------------+ | 9876543.00 | 9876543.12 | +------------+------------+ 1 row in set (0.00 sec) 会发现，flocat类型的字段会自动将值四舍五入，而decimal类型的不会，如果用flocat类型的去存与金额有关的数据的时候就会出现问题，而decimal类型的就不会。 实例2：decimal(5,2) mysql> create table t1(id1 float(5,2) default null,id2 double(5,2) default ...

binary 与 varbinary 类型和char与varchar类型是相似的，只是他们存储的是二进制数据，也就是说他们是包含字节流而不是字符流，他们有二进制字符的集合和顺序，他们的对比，排序是基于字节的数值进行的 binary与varbinary的最大长度和char与varchar是一样的，只不过他们是定义字节长度，而char和varchar对应的是字符长度。 存储和取出时对尾部空格的处理 char(N)用来存储非二进制字符串，插入时，对于少于N个字符的会自动在尾部加空格，查询时，尾部的空格就会被丢弃掉 vachar(N) 用来存储非二进制字符串，插入时，对于少于N个字符的不填补空格，查询时，尾部的空格不会被丢弃掉 binary(N)存储二进制字符串，插入进，少于N个字节的会自动在尾部加0x00，取出时，所有的字节都保留，返回定义长度的字节长度，在比较的时候，所有的字节都是有效的，并且0x00<space (space对应的是0x20) varbinary在插入不会去填补0x00字节，查询的时候也不会丢弃任何字节，在比较的时候，所有的字节都是有效的，并且0x00<space (space对应的是0x20) 大小比较时 char与varchar的字符比较中，是忽略大小写与最后的空格的，如： mysql> select 'a'='a ' , 'a'='A' , 'a'='A '; +----------+---------+----------+ | 'a'='a ' | 'a'='A' | 'a'='A ' | +----------+---------+----------+ | 1 | 1 | 1 | +----------+---------+----------+ 1 row in set (0.00 sec) 而binary及varbinary的字节比较中，所有的信息都不会被忽略，如： mysql> create table t (c BINARY(3)); Query OK, 0 rows affected (0.01 sec) mysql> insert into t set c = 'a'; Query OK, 1 row affected (0.01 sec) mysql> select hex(c), c = 'a', c ...

在mongodb中基本的概念是文档、集合、数据库 SQL术语/概念 MongoDB术语/概念 解释/说明 database database 数据库 table collection 数据库表/集合 row document 数据记录行/文档 column field 数据字段/域 index index 索引 table joins 表连接,MongoDB不支持 primary key primary key 主键,MongoDB自动将_id字段设置为主键 通过下图实例，我们也可以更直观的了解Mongo中的一些概念： 库的操作 > use test # use 库名， 创建库 switched to db test > db # 当前正在使用的库 test > show dbs # 没有刚创建的库，因为该库中没有任何数据 admin 0.000GB config 0.000GB local 0.000GB > db.dropDatabase() # 删除当前正在使用的库 { "dropped" : "test", "ok" ...

请求地址参数查询 接下来我们将使用最简单的形式来演示search API。 索引、类型查询 首先，我们先通过搜索公司的所有员工来演示搜索API的应用。 GET /employee/_search 可以发现，在请求地址中使用了company索引，employee类型，但是并没有指定文档的ID，同时使用的是_search接口。 { "took" : 1, "timed_out" : false, "_shards" : { "total" : 1, "successful" : 1, "skipped" : 0, "failed" : 0 }, "hits" : { "total" : { "value" : 5, "relation" : "eq" }, "max_score" : 1.0, "hits" : [ { "_index" : "employee", "_type" : "_doc", "_id" : "rfZt238BJHOwMxbsnp3g", "_score" : 1.0, "_source" : { "firstName" : "Mily", "lastName" : "Smith", "age" : 22, "about" : "I love Python and Java", "interests" : [ "book", "music" ] } }, { "_index" : "employee", "_type" ...

文档 在Elasticsearch中，文档这个词有特殊的含义。它指的是在Elasticsearch中被存储到唯一ID下的由最高级或者根对象（root object）序列化而来的JOSN。 一个文档不只包含了数据。它还包含了元数据（metadata）一关于文档的信息。有三个元数据元素是必须存在的，它们是： 名字 说明 _index 索引，文档存储的地方 _type 类型，文档代表的对象种类 _id 文档的唯一编号 在Elasticsearch中，文档属于一种类型，各种各样的类型存在于一个索引中。 在Elasticsearch7.x之前, 每类文档都需要定义一个类型对象，但是7.x之后，移除了_type，所有的文档类型都是默认为_doc。一个Elasticsearch集群包含多个索引，一个索引可以包含一个固定的_doc类型，类型包含了很多的文档（行），然后每个文档中又包含了很多的字段（列）。 注意：Elasticsearch 索引 在Elasticsearch中，索引这个词汇有太多的涵义，下面简单区分： 索引（名词） 如上文所说，一个索引就类似于传统关系型数据库的数据库，这里就是存储相关文档的地方。 索引（动词） 为一个文档创建索引是把一个文档存储到一个索引（名称）中的过程，这样才能被检索。这个过程非常类似SQL中的Insert语句，如果已经存在文档，新的文档则会覆盖旧的文档。 反向索引 在更新型数据库中的某列添加一个索引，比如多路搜索树（B-Tree）索引，就可以加快数据的查询速度。Elasticsearch以及Lucene使用的是一个叫做反省索引（inverted index）的结构来实现相同的功能。 索引 文档通过 索引（名词）API被索引（动词），简单地说就是将文档数据存储到索引中并使其可搜索。但是最开始需要决定将文档存储到哪里。 正如之前所说的，一个文档通过_index、_type、_id来确定它的唯一性。我们可以自己提供一个_id，也可以让index自动生成一个。 自己指定ID 为了创建员工名单，需要以下操作： 为每一个员工的文档创建索引，每个文档包含了员工的所有信息 每个文档都会被标记为employee类型 这种类型存在于company这个索引中 在实际的操作中，这些操作是非常简单的。可以将多步骤合为一个命令来完成： PUT /employee/_doc/1/ { "firstName": "John", "lastName": "Smith", "age": 25, "about": "I love Python", "interests": [ "sports", "music" ] } 在/company/empToyee/1/路径下，包含了三个部分： 名字 内容 employee 索引的名字 _doc ...

简单介绍长连接与短连接的优缺点。 短连接 client 向 server 发起连接请求 server 接到请求，双方建立连接 client 向 server 发送消息 server 回应 client 一次读写完成，此时双方任何一个都可以发起 close 操作 长连接 client 向 server 发起连接 server 接到请求，双方建立连接 client 向 server 发送消息 server 回应 client 一次读写完成，连接不关闭 后续读写操作… 长时间操作之后 client 发起关闭请求 优缺点分析 长连接可以省去较多的 TCP 建立和关闭的操作，节约时间。但是如果用户量太大容易造成服务器负载过高最终导致服务不可用 短连接对于服务器来说实现起来较为简单，存在的连接都是有用的连接，不需要额外的控制手段。但是如果用户访问量很大, 往往可能在很短时间内需要创建大量的连接，造成服务器响应速度过慢 总结 小的 WEB 网站的 http 服务一般都用短链接，因为长连接对于服务端来说会耗费一定的资源来让套接字保持存活。 对于中大型 WEB 网站一般都采用长连接，好处是响应用户请求的时间更短，用户体验更好，虽然更耗硬件资源一些，但这都不是事儿。另外，数据库的连接用长连接，如果用短连接频繁的通信会造成 socket 错误。

SQL注入，旁注，XSS跨站，COOKIE欺骗，DDOS，0day 漏洞，社会工程学 等等等等，只要有数据交互，就会存在被入侵风险！哪怕你把网线拔掉，物理隔绝，我还可以利用传感器捕捉电磁辐射信号转换成模拟图像。你把门锁上，我就爬窗户；你把窗户关上，我就翻院墙；你把院墙加高，我就挖地洞。。。道高一尺魔高一丈，我始终坚信计算机不存在绝对的安全，你攻我防，此消彼长，有时候，魔与道只在一念之间。 下面，就让我们一起推开计算机中那另一扇不为人知的门 CSRF 基本概念 CSRF（Cross-site request forgery）：跨站请求伪造。 攻击原理 用户是网站 A 的注册用户，且登录进去，于是网站 A 就给用户下发 cookie。 从上图可以看出，要完成一次 CSRF 攻击，受害者必须满足两个必要的条件： （1）登录受信任网站 A，并在本地生成 Cookie。（如果用户没有登录网站 A，那么网站 B 在诱导的时候，请求网站 A 的 api 接口时，会提示你登录） （2）在不登出 A 的情况下，访问危险网站 B（其实是利用了网站 A 的漏洞）。 我们在讲 CSRF 时，一定要把上面的两点说清楚。 温馨提示一下，cookie 保证了用户可以处于登录状态，但网站 B 其实拿不到 cookie。 防范措施 判断请求头中的 Referer 这个字段记录的是请求的来源。比如前端Vue页面 http://localhost:8080/#/showbooks上调用了服务端Django的接口 http://127.0.0.1:8000/books/?page=2&page_size=10， 那么在服务端，就可以通过 Referer 判断这个请求是来自哪里。 在实际应用中，这些跟业务逻辑无关的操作往往会放在拦截器中（或者说过滤器，不同技术使用的名词可能不同）。意思是说，在进入到业务逻辑之前，就应该要根据 Referer 的值来决定这个请求能不能处理。 用Flask 的话可以使用装饰器；在Django 中是叫中间件。每种技术它走的流程其实都一样。 而在 Django 可以通过以下代码获取对应信息 request.META['HTTP_REFERER'] # 来路 request.META.get("HTTP_USER_AGENT") # 请求头 在Flask中，则获取方式不同。 request.referrer # 来路 request.headers.get('User-Agent') # 请求头 但要注意的是，Referer 是浏览器设置的，在浏览器兼容性大不相同的时代中，如果存在某种浏览器允许用户修改这个值，那么 CSRF 漏洞依然存在。 在请求参数中加入 csrf token 讨论 GET 和 POST 两种请求，对于 GET，其实也没什么需要防范的。为什么？ ...

算法 : 内功心法, 是解决问题的一种思想 时间复杂度 $T(n)$ 由于每台机器的性能有所差别，所有其执行相同代码的时间也长短不一，故而推出一种计量方式，统计代码执行基本运算（函数调用需要看其源码的基本运算）的数量（n) 来确定一个算法的优劣，其中基本运算的循环按乘法计算，顺序结构按加法计算，分支结构取最大值。 for a in range(0, 1000): for b in range(0, 1000): for c in range(0, 1000): if a+b+c == 1000 and a**2 + b**2 + c**2: print('a,b,c,: {}, {}, {}'.format(a,b,c)) 上述代码的时间复杂度为 $T = 1000 * 1000 * 1000 * 2$ 那么如果将上述代码中的 1000 改为 2000， 则 $T = 2000 * 2000 * 2000 * 2$ 由于上述同样的代码由于不同的参数的 T 都不同，我们便将其统一成 N，这样上述代码的时间复杂度可以表示成： $T = N * N * N * 2$ 同样的我们抓住其主要 “矛盾” ，观其大，再将其简化成 $T= N^3$ 这样同一段代码的时间复杂度便不会根据其参数而发生改变了。 大 $O$ 标记法 $O()$ 其实和求极限的原理相似，抓住问题的主要矛盾，忽略那些细枝末节，也就像前面的 $T$的最后的样子。 时间复杂度的几条基本规则 基本步骤: 即只有常数项, 算作 $O(1)$ ...

哈希表 哈希表是 key-value 类型的数据结构，通过关键码值直接进行访问。通过散列函数进行键和数组的下标映射从而决定该键值应该放在哪个位置，哈希表可以理解为一个键值需要按一定规则存放的数组 。 哈希函数 装填因子 冲突 起因 假设我们存在一个简单的键值对结构，键 - 员工号，值 - 是否在岗。现在需要这样一个功能，输入员工号，返回该员工是否在岗，理想的方法是创建一个长度为 Max(员工号) 的数组，数组下标就是员工号，数组中的值用 0 和 1 对是否在岗进行区分，这样只需要 O(1) 的时间复杂度就可以完成操作，但是扩展性不强，存在以下问题。 假设新进员工的员工号比 Max(员工号) 还要大，这就需要重新申请数组进行迁移操作。 假设一种极端的情况，存在两个员工，员工号分别是 1 和 100000000001，这样子的话按照先前的设计思路，是会浪费很大的存储空间的。 上面两点，第一点是因为数组的固定申请大小的属性所决定，而第二点就是引入哈希表的原因，会不会存在一个方法，让一个大员工号变小而而且没有标记，哈希函数便产生，假设此处的哈希规则是除 3 取模，则员工 1 得到的哈希值是 1，员工 100000000001 得到的哈希值是 2，这样的话按照设计思路，只需要一个大小为 2 的数组便可以覆盖了，这就是哈希思想。 算法中时间和空间是不能兼得的，哈希表就是一种用合理的时间消耗去减少大量空间消耗的操作，这取决于具体的功能要求。 哈希函数 上面的例子中哈希函数的设计很随意，但是从这个例子中我们也可以得到信息： 哈希函数就是一个映射，因此哈希函数的设定很灵活，只要使得任何关键字由此所得的哈希函数值都落在表长允许的范围之内即可； 并不是所有的输入都只对应唯一一个输出，也就是哈希函数不可能做成一个一对一的映射关系，其本质是一个多对一的映射，这也就引出了下面一个概念–冲突。 冲突 只要不是一对一的映射关系，冲突就必然会发生，还是上面的极端例子，这时新加了一个员工号为 2 的员工，先不考虑我们的数组大小已经定为 2 了，按照之前的哈希函数，工号为 2 的员工哈希值也是 2，这与 100000000001 的员工一样了，这就是一个冲突，针对不同的解决思路，提出以下不同的解决方法。 开放地址 开放地址的意思是除了哈希函数得出的地址可用，当出现冲突的时候其他的地址也一样可用，常见的开放地址思想的方法有线性探测再散列，二次探测再散列，这些方法都是在第一选择被占用的情况下的解决方法。 再哈希法 这个方法是按顺序规定多个哈希函数，每次查询的时候按顺序调用哈希函数，调用到第一个为空的时候返回不存在，调用到此键的时候返回其值。 链地址法 将所有关键字哈希值相同的记录都存在同一线性链表中，这样不需要占用其他的哈希地址，相同的哈希值在一条链表上，按顺序遍历就可以找到。 公共溢出区 其基本思想是：所有关键字和基本表中关键字为相同哈希值的记录，不管他们由哈希函数得到的哈希地址是什么，一旦发生冲突，都填入溢出表。 装填因子α 一般情况下，处理冲突方法相同的哈希表，其平均查找长度依赖于哈希表的装填因子。哈希表的装填因子定义为表中填入的记录数和哈希表长度的壁纸，也就是标志着哈希表的装满程度。直观看来，α越小，发生冲突的可能性就越小，反之越大。一般 0.75 比较合适，涉及数学推导。

Web应用程序是使用HTTP协议传输数据的。HTTP协议是无状态的协议。一旦数据交换完毕，客户端与服务器端的连接就会关闭，再次交换数据需要建立新的连接。这就意味着服务器无法从连接上跟踪会话。要跟踪该会话，必须引入一种状态保持机制。 状态保持 修改Http协议，使得它支持状态保持(难做到) Cookies：通过客户端来保持状态信息 Cookie是服务器发给客户端的特殊信息 Cookie是以文本的方式保存在客户端，每次请求时都带上它 Session：通过服务器端来保持状态信息 Session是服务器和客户端之间的一系列的交互动作 服务器为每个客户端开辟内存空间，从而保持状态信息 由于需要客户端也要持有一个标识(id)，因此，也要求服务器端和客户端传输该标识， 标识(id)可以借助Cookie机制或者其他的途径来保存 COOKIE机制 Cookie，有时也用其复数形式Cookies，指某些网站为了辨别用户身份、进行session跟踪而储存在用户本地终端上的数据（通常经过加密）。 由于HTTP是一种无状态的协议，服务器单从网络连接上无从知道客户身份。怎么办呢？就给客户端们颁发一个通行证吧，每人一个，无论谁访问都必须携带自己通行证。这样服务器就能从通行证上确认客户身份了。这就是Cookie的工作原理。 Cookie是由服务器端生成，发送给User-Agent（一般是浏览器），浏览器会将Cookie的key/value保存到某个目录下的文本文件内，下次请求同一网站时就发送该Cookie给服务器（前提是浏览器设置为启用cookie）。Cookie名称和值可以由服务器端开发自己定义，这样服务器可以知道该用户是否是合法用户以及是否需要重新登录等。服务器可以利用Cookies包含信息的任意性来筛选并经常性维护这些信息，以判断在HTTP传输中的状态。 Cookie是存储在浏览器中的一段纯文本信息，建议不要存储敏感信息,如密码。 Cookie具有不可跨域名性。根据Cookie规范，浏览器访问Google只会携带Google的Cookie，而不会携带Baidu的Cookie。Google也只能操作Google的Cookie，而不能操作Baidu的Cookie。 基本特点 Cookie以键值对Key-Value形势进行信息的存储,只能保存字符串对象，不能保存对象类型 Cookie基于域名安全，不同域名的Cookie是不能互相访问的 Cookie保存在客户端,需要客户端浏览器的支持，缺点：浏览器用户可能会禁用Cookie SESSION机制 如果说 Cookie机制是通过检查客户身上的“通行证”来确定客户身份的话，那么Session机制就是通过检查服务器上的“客户明细表”来确认客户身份。Session相当于程序在服务器上建立的一份客户档案，客户来访的时候只需要查询客户档案表就可以了。 每次客户端发送请求，服务端都检查是否含有sessionId。 如果有，则根据sessionId检索出session并处理；如果没有，则创建一个session，并绑定一个不重复的sessionId。 基本特点 状态信息保存在服务器端。这意味着安全性更高，可以存储敏感、重要的信息，支持更多字节，缺点：Session共享问题 通过类似与Hashtable的数据结构来保存，能支持任何类型的对象(session中可含有多个对象) 保存会话id的技术,依赖于 Cookie。默认情况下在客户端与服务器端之间通过cookie方式传递 SeesionId 总结 两种状态跟踪机制的比较 Cookie Session 存储位置 保持在客户端 保存在服务器端 存储类型 只能保持字符串对象 支持各种类型对象 实现机制 通过过期时间值区分Cookie的类型 ...