NoSQLBooster操作Mongodb的基本使用。 1.NoSQLBooster简介。 NoSQLBooster （前身是 MongoBooster）是MongoDB CLI界面中非常流行的GUI工具。它正式名称为MongoBooster。NoSQLBooster是一个跨平台，它带有一堆mongodb工具来管理数据库和监控服务器。这个Mongodb工具包括服务器监控工具，Visual Explain Plan，查询构建器，SQL查询，ES2017语法支持等等…它有免费，个人和商业版本，当然，免费版本有一些功能限制。NoSQLBooster也可用Windows，MacOS和Linux。 2.NoSQLBooster的安装。 官网上下载巨慢，所以我已经上传至网盘。扫码后台回复1005，获取下载地址。下载完成后双击运行即可。 3.mongodb的常用命令。 1.show dbs ( show databases) 显示所有数据库。 use 数据库名 | 使用数据库，不存在就创建。 3.db 查看当前数据库名 4.show collections （显示所有集合） 4.mongodb中文档的增删改查 4.1 添加文档。 db..insert() –这里的conllecton是我们表的名字。 –当我们插入文档时，如果没有指定id,会自动创建，该属性是唯一标识。 db..insertOne() –插入一个文档 db..inserttMany() –插入多个文档，必须是以数组的形式。 4.2 查询文档。 db..find() –find() , 用来查询结合中所有符合条件的文档。find可以接受一个对象作为参数。 {} 表示查询集合中所有的文档 find返回的是一个数组 db.collection.findOne() –用来查询集合中符合条件的第一个文档。 –返回的就是一个文档对象。 db.collection.find({}).count(); --查询所有结果的数量。 4.3.修改文档 db.collection.update(查询条件，新对象) –update（）默认情况下会使用新对象来替换旧的对象。（即新对象会覆盖之前所有的属性，很不友好） –update()默认只会修改一个。 我们使用$set来修改指定属性。 $unset来删除指定属性 db.collection.updateMany() –修改多个文档。 4.4 . 删除文档。 删除文档 db.collection.remove() db.collection.deleteOne() db.collection.deleteMany() – 如果remove第二个参数传递一个true，则只会删除一个 –如果只传递一个空对象作为参数，那么会删除所有。db.collection.remove({}) db.collection.deleteOne()

简介 加固平板电脑通常指的是工业平板电脑，即工业用电脑，与商业电脑不同的是，工业电脑在工业生产环境中须具备适用恶劣、严酷的环境。 在普通人看来，恶劣环境就是灰尘、油污、寒冬或酷热的天气等。实际上，工业中的恶劣环境还包括：风沙、霉菌、雨雪、盐、喷雾、防电磁干扰、腐蚀与划痕、灰尘、冲击、震动和高低温等等。所包含的环境有：仓储、军工、国防、航空、工厂自动化、交通运输、现场维修、消防石油天然气勘探和钻采业等行业。 加固型平板电脑跟商用电脑一样，也是从笨重的计算机发展而来，当时称加固计算机。但随着科技的发展，从加固计算机演变成加固平板电脑，从有限的适应环境到适应有限的环境，加固平板电脑也成为工业平板电脑中的“战斗机”。 加固型平板电脑——特殊行业必备武器 对于工业平板电脑及加固型平板电脑，我们通常会比较陌生，与商用平板电脑不同，工业平板电脑更加注重外部的环境耐受性以及更高效可靠的运算性能，虽然我们很难真正去体验工业平板电脑给我们带来的直观感觉，但在实际生活中，每一天他们都在幕后默默地发挥着巨大的作用，是特殊行业必备的武器。以下从几个行业应用来介绍他的超强特性： 野外侦查测绘：随着计算机、地面测量仪器、数字化测图软件应用的迅速发展、数字化测图逐渐替代传统的人工测量手段，成为测绘生产、水利水电工程、土地管理等测绘业务的主流模式。勘探行业艰苦、恶劣的作业环境决定了信息化管理平台必须具备四种要求：在不同环境下轻松安装，基于PC的内部SAP系统和公司集成网络；设备必须坚固耐用，防水、抗震；整机能宽温工作，工作温度在-20~+50℃；接口丰富，能实现运行状态实时采集，数据可靠传输。因此，加固平板电脑作为适合的设备应用在此。在野外测图的过程中，加固平板电脑可随时修测，做到“站站清、日日清”，可有效防止侧错、漏测和重测、返工等其他人工测绘工作中所无法避免的问题。 军事、国防：自计算机问世以来，加固计算机技术及应用就说到军队、政府以及各行各业的高度重视，目前加固计算机技术与应用已成为我国国防工业的重要课题，根据国家关于“要适应新形势，积极探索军民结合，寓军于民的新途径、新方法”的指示精神，为把先进的加固技术、设备、产品用于国家和军队现代化建设，同时也为我国从事加固计算机技术研制、应用的单位提供交流平台。目前，国防领域仍是加固计算机的一个需求稳定的、规模较大的应用领域，但其他行业的新兴市场也对加固计算机提出了巨大需求。军用计算机的研制开发和装备应用水平是衡量一个国家国防现代化和军事实力的重要尺度。 消防：众所周知，消防员的工作每时每刻都面临着危险，数以万计消防人员都曾在施救过程中受过伤，这些人大部分都是灭火前线和没有设备掩护的情况下灼伤。如果能使用到一些技术/设备能够在火灾这种复杂的环境下仍能正常工作，同时能够报告救援对象的具体位置，那么就能减少很多伤亡事故，这种设备无疑非加固型计算机莫属。消防部门一直在寻找这种技术设备，在消防车里装一台设备，能够实现获取现场信息、指挥消防人员开展救援，并保持与在救火前线的联系，这套设备必须是可移动的，而且非常坚固，可靠；必须支持现有的无线装置设备（802.111）；还能像操作员统计消防车使用情况，如氧气消耗、压力状态；该系统还需要有报警功能和撤离通知，更重要的是，如果消防员无法接到指令，他们需要能够直接通过无线电联系，以确保救援有效进展，针对此项目，现都有一套完整的解决方案，为消防员的伤害提送有效保障。 钻井：钻井平台对计算机硬件的可靠性要求非常高。要求产品防爆、耐腐蚀、系统稳定。通常都需要监控系统采用冗余的备份系统（包括软件冗余和硬件冗余两部分）。如PLC的cpu模块以及和工控机通讯的通讯模块都采用冗余方式，即采用2块CPU模块、2块通讯模块、及相应的冗余控制。控制系统软件在加固防爆平板电脑上独立运行。每台加固防爆平板电脑有独立的通道与PLC进行通讯。通过平台的管理局域网，可以把每天的生产数据和一段时间的历史生成数据，汇总处理后传输到陆地的生产管理部门，使管理部门能及时掌握平台的生产情况，对将来的生产计划进行及时的调整。 加固平板电脑发展局势：未来去向与小型化、轻型化、新型应用蓝海愈发宽泛 伴随我国特种行业如海事、军事、高铁等领域不断的发展，特种行业用户需求也在不断提升，加固电脑产品，尤其是加固平板电脑的市场空间将不断增大。为了能更好的满足用户的使用需求，加固设备的发展也出现了一些新的发展趋势。 在加固计算机领域，加固笔记本产品和加固手持产品的应用都已经较为成熟，而功能介于其间的平板电脑，由于较小的体积和较强的计算、扩展性能，越来越多的得到了野外工作者的青睐。 随着特种行业用户对加固电脑产品使用需求的不断提升，使加固电脑产品越来越多的进入到普通公众的视线。这亦是一个好的方向，医疗、食品、沙漠风电、海上风电等均可列为服务领域。矿井应用和人防应用（包括应急救援、基础设施、预警设施）将是近两年加固计算机增长较大的两个新兴市场。 这些新型应用市场对加固计算机的性能和功能提出了新的要求。比如，煤矿行业应用要求加固笔记本不仅坚固，具有高防护等级，还必须有防爆功能，也就是在运行过程中不能产生电器火花。在食品安全应用中，由于经常要消毒、清洗，所以要求防护等级更高、密封性更好、不能生锈。而对人防等应急救援应用来说，应急通信功能就显得非常重要，因而要求加固计算机支持卫星通信、3G等通信技术。 加固三防平板电脑价格贵的原因在于： 耐盐雾：金属元器件要耐盐雾、耐腐蚀。在一些户外作业、航海的场景，平板的金属器件，尤其是裸漏的部分，耐盐雾、耐腐蚀是基本要求。防刮花：屏幕可以防刮花。这就需要在触摸屏上配置康宁大猩猩玻璃，硬度达到7H以上，没有保护膜也能防刮花。耐高低温：所有的部件必须耐高低温。因为要确保整机可以在宽温下正常工作、安全存储。各物料的工作温度和存储温度的范围必须更大，一些容易发热的部分甚至要求器件能承受100℃以上的高温。耐磨损：外壳能够耐磨损。三防平板在各种工业环境中使用，容易磨损，为了保证产品的有效寿命，会使用一些耐磨物料，尤其是外壳部分。防爆：整机符合工业防爆。这对整机的电气性能、密闭性能都有严格的要求。 从上面介绍可以看出三防平板的成本是多方面的。前期需要投入大量研发费用、开模费用、人工费用；后期需要投入足够的营销和服务费；此外，三防平板“三高一严”的特点增加了每个平板的成本。其中磨具和设计成本占大部分。所以选择的时候一定不能简单的比较价格，要看质量和性能的稳定性是否能满足应用要求，尤其是要看厂家的实力。否则我们买的产品不靠谱或者后期无法维护，那就得不偿失了。

冯·诺依曼结构，又称为普林斯顿体系结构，是一种将程序指令存储器和数据存储器合并在一起的存储器结构。取指令和取操作数都在同一总线上，通过分时复用的方式进行；缺点是在高速运行时，不能达到同时取指令和取操作数，从而形成了传输过程的瓶颈。由于程序指令存储地址和数据存储地址指向同一个存储器的不同物理位置，因此程序指令和数据的宽度相同。 冯诺依曼结构：冯诺依曼结构则是将逻辑代码段和变量统一都存储在内存当中，他们之间一般是按照代码的执行顺序依次存储。这样就会导致一个问题，如果当程序出现BUG的时候，由于程序没有对逻辑代码段的读写限定，因此，他将拥有和普通变量一样的读写操作权限。于是就会很容易的死机，一旦他的逻辑执行出现一点该变就会出现非常严重的错误。但是，冯诺依曼结构的好处是可以充分利用有限的内存空间，并且会使CPU对程序的执行十分的方便，不用来回跑。 哈佛结构是一种将程序指令存储和数据存储分开的存储器结构，它的主要特点是将程序和数据存储在不同的存储空间中，即程序存储器和数据存储器是两个独立的存储器，每个存储器独立编址、独立访问，目的是为了减轻程序运行时的访存瓶颈。 哈佛结构：哈佛结构就是将程序的逻辑代码和变量分开存放的一种结构，而他们存放的位置可以是形同的也可以是不同的，总是只要是分成两个部分单独访问的结构都可以叫哈佛结构。（例如：51的程序的逻辑代码段放在ROM中，而变量部分则放在ROM中；而ARM的逻辑代码和变量都是存放在RAM（内存）中的，但是，它在内存中划分了两部分的空间，其中一部分放逻辑代码，另一部分方变量。之间不会相互干扰）哈佛结构的优点就是逻辑代码和变量单独存放，使之不会相互干扰，进而当程序出BUG的时候，最多只会修改变量的值，而不会修改程序的执行顺序（逻辑关系）。因此，这种结构大量应用在嵌入式编程当中。 总得来说，哈佛机构的高性能体现在在单片机、DSP芯片平台上运行的程序种类和花样较少，因为各个电子娱乐产品中的软件升级比较少，应用程序可以用汇编作为内核，最高效率的利用流水线技术，获得最高的效率。 冯诺依曼结构主要是基于电脑购买者对电脑的使用途径不同—-各种娱乐型用户、各种专业开发用户等，且安装的软件的种类繁多，升级频繁，多种软件同时运行时处理的优先级比较模糊，因特尔芯片不具备彻底智能分配各程序优先级和流水线的机制，机械的分配优先和流水线反而容易使用户不便。 冯氏结构简单、易实现、成本低，但效率偏低；哈佛结构效率高但复杂，对外围设备的连接与处理要求高，十分不适合外围存储器的扩展。现在的处理器，依托CACHE的存在，已经很好的将二者统一起来了。现在的处理器虽然外部总线上看是诺依曼结构的，但是由于内部CACHE的存在，因此实际上内部来看已经类似改进型哈佛结构的了。 CISC与RISC的区别： CISC（复杂指令集）:复杂指令集就是CPU在工作的时候需要有很多的汇编指令来完成，它可以用一个汇编指令来完成一件复杂的工作。例如：乘法，加法，乘加，乘减等处理的时候，他会每个处理方式用一条指令来完成。因此这种设计实际上是很强大的，因为同样处理一个运算，它可以用一个机器周期就可以完成了。但是其内部的硬件设计就相对而言的比较复杂了一些。而且，这样的设计势必就会遭成功耗的增加。例如现在的大部分PC机的处理器都是这种的。51单片机也是这种方式的。 RISC（精简指令集）：相对于复杂指令集而言，精简指令集所需要的汇编指令就会少很多了。例如：在完成（1+1）×（2-1）这样的运算的时候，第一次先算1+1等于2然后再算2-1等于1，最后在算2×1等于2。这样他就要经历好几个机器周期才能完成一次运算。而如果用复杂指令集的话可能一次就可以算出来结果了。由于现在的CPU主频基本上在原料不变的情况下是很难再提高他的（主频）运算速度了。所以，精简指令集的CPU在单核的效率上是远不如复杂指令集的CPU的。因此，为了达到与复杂指令集的CPU同样的运算效率，现在的手机经常会增加内核的数量来提升自身的处理效率。 地址总线、数据总线和控制总线的区别（这里的总线主要指外部总线，不包括内核的总线）： 地址总线（Address Bus）：当CPU要处理数据的时候首先地址总线会根据要处理的数据的地址在内存中找到要处理的数据，然后再对其进行相应的处理。也就是说，地址总线的宽度决定了CPU能够处理的数据地址的总量的大小。由于地址总线总是由CPU发起的寻址要求，因此数据总线只能由CPU主动向外部寻找它所需要的地址，而不能被外部的IO主动使用。因此，地址总线是单向（只能由CPU主动去读而不会对其进行写）三态（高电平、低电平、高阻态）的。 数据总线（Data Bus）：当CPU需要读取或写入数据的时候由地址总线先去寻址，然后再由数据总线对所读到的地址进行读或写操作（CPU一次读写的数据总量由数据总线的宽度决定）。最终实现CPU所要实现的相应功能。由于CPU会通过数据总线对所要处理的地址进行读和写两种方式的操作。因此，数据总线是双向三态的。 控制总线（Control Bus）：当CPU要对外部的外设（IO设备或内存）进行操作的时候，控制总线会对相应的外设发出相应的控制指令，然后再由数据总线对其进行操作。由于控制总线要对所有的外设进行控制，因此，他是双向的且十分的灵活，而其总线的宽度也是不确定的，主要有外设的数量决定其宽度。 统一编址和独立编址的区别： 要明白统一编址和独立编址的区别首先要知道CPU在处理数据的时候其实是要先由控制总线发送控制指令，然后再对外设（这里的外设包括IO设备和内存）进行寻址的操作，只有找到了要操作的硬件或内存的地址之后才能对其进行相应的操作。而这个寻址的方式是由CPU对地址的编址方式决定的。而编址方式就分为统一编址和独立编址。 统一编址：统一编址就是当CPU要对IO设备进行操作的时候，就直接由地址总线进行寻址，因为地址总线的宽度是一定的，也就是所寻址的范围是一定的。而如果由它直接对IO设备进行寻址，那势必会占用有限的地址，进而会导致对其能够操作的内存大小就会有所限制。这也就导致了地址总线所能寻到的内存地址并不和自己的总线宽度对应上。（假如一个32位宽度的地址总线本来可以寻址4GB的内存地址，但是由于它一般分外设占用了他的地址，因此，他所能使用的内存就会小于4GB。） 独立编址：独立编址的CPU在对IO设备进行操作的时候会有专门的操作指令，而不会用内存操作指令，这样就会使地址总线仅服务于内存，而不会被其他IO外设占用。也因此会使内存的大小等于地址总线的宽度。

SRC漏洞定级标准 分资产，核心资产，一般资产，边缘资产 严重漏洞： 1.不需要登录直接获取设备root权限的漏洞，包括但不限于上传Webshell，任意代码执行，远程命令执行等 2.不需要登录直接导致严重的信息泄露漏洞，包括但不限于重要数据库的SQL注入、系统权限控制不严格等导致的敏感数据泄露漏洞等 3.不需要登录直接导致严重影响的逻辑漏洞，包括但不限于核心账户体系的帐密校验逻辑、支付逻辑漏洞等 高危漏洞： 1.需要登录的重要业务铭感数据信息泄露漏洞，包括但不限于重要用户信息、配置信息、数据文件信息等 2.需要登录的重要业务逻辑漏洞，包括但不限于权限绕过等 3.包含重要业务铭感信息的非授权访问，包括但不限于绕过认证直接访问管理后台、后台弱密码、可直接获取大量内网铭感信息的SSRF等 4.影响应用服务正常运转，包括但不限于应用层拒绝服务等 中危漏洞： 1.不需要交互对用户产生危害的安全漏洞，包括但不限于一般页面存储型XSS等 2.普通信息泄露漏洞，包括但不限于用户信息泄露和业务铭感信息泄露等 3.普通的逻辑设计缺陷和流程缺陷，包括但不限于越权查看非核心系统的订单信息、记录等 4.其他操作中度影响的漏洞，例如：没有敏感信息的SQL注入、无法回显的SSRF等 低危漏洞: 1.轻微信息泄露，包括但不限于路径信息泄露、svn信息泄露、phpinfo、日志文件、配置信息等 2.本地拒绝服务，包括但不限于客户端本地拒绝服务等引起的问题 3.可能存在安全隐患但利用成本很高的漏洞，包括但不限于需要用户连续交互的敏感安全漏洞，例如：解析漏洞、可被暴力破解接口等 无效: 1.不涉及安全问题的bug，包括但不限于功能缺陷、网页乱码、样式混乱、静态文件遍历、应用兼容性等问题 2.无法利用的漏洞，包括但不限于self-xss、无敏感操作的CSRF、无意义的异常堆栈、内网IP地址/域名泄露 3.不能直接反映漏洞存在的其他问题，包括但不限于纯属猜测的问题 扫描器的漏洞定级按照扫描的标准执行即可 第三方组件CVE漏洞的分级标准，可以采用CVSS（弱点评价体系）评分标准 https://www.first.org/cvss/calculator/3.1 常见漏洞定级标准 SQL注入漏洞 定级标准： 严重：能够利用SQL注入获取webshell 高危：能够验证存在的SQL注入 XSS漏洞 定级标准： 存储型XSS：高危 反射型XSS：低危 命令执行漏洞 定级标准： 严重：能够执行命令，能够验证出来 低危：无法验证出来，或者参数不可控 风险：无法验证出来，或者参数不可控 CRLF漏洞 定级标准：中危 HOST注入攻击 定级标准：低危 文件上传漏洞 定级标准： 严重：能够利用文件上传漏洞，或者租户其他漏洞，能够获取设备权限 高危：能够绕过防御规则，能执行js探针，给产品线演示出效果 中危：能够绕过防御规则，成功上传文件，但是文件重命名了。文件路径、文件名很难找到，或者需要利用条件竞争子类的漏洞去触发 低危：能够任意文件上传，但是没有执行权限，无法造成伤害 目录遍历漏洞 定级标准：中危 硬编码 定级标准：高级 目录穿越/任意文件读取/下载漏洞 定级标准： 高危：任意读取文件 中危：读取文件有限制 任意文件删除 定级标准： 严重：能够越目录删除任意文件 高危：被限制在web目录，能删除任意web文件 SSRF漏洞 定级标准： 严重：能够租户其他漏洞，获取设备权限 高危：能够利结合各种协议造成实际伤害 中危：能够证明存在SSRF，可以利用漏洞探测内网 低危：证明存在SSRF，但是无法利用

三种分页的实现方式 (1)每次取查询结果的所有数据，然后根据页面显示指定的记录 (2)根据页面只取一页的数据，然后显示这一页，这里要构造sql语句 (3)取一定页数的数据，就是前两种的折中 实现分页的步骤： 1.创建一个用于封装分页相关属性及操作的类 2.从页面增加分页导航条的功能 3.实现分页查询功能，从页面请求->Servlet->DAO的实现 这里还要注意的是这些数据是放在request还是session中，这里一一讨论 1.一般不会放在session中，因为会占用大量内存，所以要放在request里面。 优点：实现比较简单，查询速度比较快。 缺点：占用内存多一些，网络传输数据多。 对于数据量比较少的查询这种方法比较合适。这里有人把数据放在session中，这样换页的时候就不用重新查询，但是这样是极其不好的，强烈建议不要这样使用。 2.肯定不会放在session中，因为放在session中没有意义。 优点：占用内存少。 缺点：比较麻烦，必须先获得查询结果的总数，因为要知道有多少纪录才知道有多少页。另外要构造分页查询语句，对于不同的数据库是不一样的。 一.借助数组进行分页 原理：进行数据库查询操作时，获取到数据库中所有满足条件的记录，保存在应用的临时数组中，再通过List的subList方法，获取到满足条件的所有记录。 实现： 首先在dao层，创建StudentMapper接口，用于对数据库的操作。在接口中定义通过数组分页的查询方法，如下所示： List 创建StudentMapper.xml文件，编写查询的sql语句： 可以看出再编写sql语句的时候，我们并没有作任何分页的相关操作。这里是查询到所有的学生信息。 接下来在service层获取数据并且进行分页实现： 定义IStuService接口，并且定义分页方法： 通过接收currPage参数表示显示第几页的数据，pageSize表示每页显示的数据条数。 创建IStuService接口实现类StuServiceIml对方法进行实现，对获取到的数组通过currPage和pageSize进行分页： 通过subList方法，获取到两个索引间的所有数据。 最后在controller中创建测试方法： 通过用户传入的currPage和pageSize获取指定数据。 二.借助Sql语句进行分页 在了解到通过数组分页的缺陷后，我们发现不能每次都对数据库中的所有数据都检索。然后在程序中对获取到的大量数据进行二次操作，这样对空间和性能都是极大的损耗。所以我们希望能直接在数据库语言中只检索符合条件的记录，不需要在通过程序对其作处理。这时，Sql语句分页技术横空出世。 实现：通过sql语句实现分页也是非常简单的，只是需要改变我们查询的语句就能实现了，即在sql语句后面添加limit分页语句。 首先还是在StudentMapper接口中添加sql语句查询的方法，如下： List 接下来还是在IStuService接口中定义方法，并且在StuServiceIml中对sql分页实现。 ql分页语句如下：select * from table limit index, pageSize; 所以在service中计算出currIndex：要开始查询的第一条记录的索引。 三.拦截器分页 上面提到的数组分页和sql语句分页都不是我们今天讲解的重点，今天需要实现的是利用拦截器达到分页的效果。自定义拦截器实现了拦截所有以ByPage结尾的查询语句，并且利用获取到的分页相关参数统一在sql语句后面加上limit分页的相关语句，一劳永逸。不再需要在每个语句中单独去配置分页相关的参数了。。 首先我们看一下拦截器的具体实现，在这里我们需要拦截所有以ByPage结尾的所有查询语句，因此要使用该拦截器实现分页功能，那么再定义名称的时候需要满足它拦截的规则(以ByPage结尾)， import org.apache.ibatis.executor.Executor; import org.apache.ibatis.executor.parameter.ParameterHandler; import org.apache.ibatis.executor.resultset.ResultSetHandler; import org.apache.ibatis.executor.statement.StatementHandler; import org.apache.ibatis.mapping.MappedStatement; import org.apache.ibatis.plugin.*; import org.apache.ibatis.reflection.MetaObject; import org.apache.ibatis.reflection.SystemMetaObject; import java.sql.Connection; import java.util.Map; import java.util.Properties;

版本 在按照说明文档的要求操作后还是报错 加载StreamingAssets/sp_human_face_68失败 最终我发现是我的工程目录下有中文名，一定要在非中文目录在建立工程！！！！

使用mysql启动时，提示了一个错误！ High Severity Error Unhandled Exception Root element is missing. 点击show details按钮显示 at System.Xml.XmlTextReaderImpl.Throw(Exception e) at System.Xml.XmlTextReaderImpl.ParseDocumentContent() at System.Xml.XmlTextReaderImpl.Read() at System.Xml.XmlTextReader.Read() at System.Xml.XmlReader.MoveToContent() at System.Xml.XmlReader.ReadStartElement(String name) at MySQL.Utility.Classes.CustomSettingsProvider.GetPropertyValues(SettingsContext context, SettingsPropertyCollection collection) at System.Configuration.SettingsBase.GetPropertiesFromProvider(SettingsProvider provider) at System.Configuration.SettingsBase.GetPropertyValueByName(String propertyName) at System.Configuration.SettingsBase.get_Item(String propertyName) at System.Configuration.ApplicationSettingsBase.GetPropertyValue(String propertyName) at System.Configuration.ApplicationSettingsBase.get_Item(String propertyName) at MySql.Notifier.Properties.Settings.get_AutoAddPattern() at MySql.Notifier.Classes.Program.ChangeAutoAddPatternDefaultValue() at MySql.Notifier.Classes.Program.Main(String[] args) 原因我不清楚 解决办法是：删除C:\Users\Administrator\AppData\Roaming\Oracle\MySQL Notifier文件夹的所有文件，重新启动就好了

1.上传服务端 2.上传Java 3.接下来是安装64位系统兼容32位组建 输入命令yum -y install glibc.i686 4.防火墙开启设置#/sbin/iptables -I INPUT -p tcp --dport 29000 -j ACCEPT (29000默认游戏一线端口) #/sbin/iptables -I INPUT -p tcp --dport 39000 -j ACCEPT (39000默认游戏二线端口) #/sbin/iptables -I INPUT -p tcp --dport 49000 -j ACCEPT (49000默认游戏三线端口) #/sbin/iptables -I INPUT -p tcp --dport 59000 -j ACCEPT (59000默认游戏四线端口) #/sbin/iptables -I INPUT -p tcp --dport 443 -j ACCEPT (443默认后台端口) #/sbin/iptables -I INPUT -p tcp --dport 3306 -j ACCEPT (3306数据库端口) #/sbin/iptables -I INPUT -p tcp --dport 88 -j ACCEPT (88jetty后台端口)

一，索引前传 在了解数据库索引之前，首先有必要了解一下数据库索引的数据结构基础，那么什么样的数据结构可以作为索引呢？ B-tree是最常用的用于索引的数据结构。因为它们是时间复杂度低， 查找、删除、插入操作都可以可以在对数时间内完成。另外一个重要原因存储在B-Tree中的数据是有序的。数据库管理系统(RDBMS)通常决定索引应该用哪些数据结构。但是，在某些情况下，你在创建索引时可以指定索引要使用的数据结构。 B+是一个树数据结构，通常用于数据库和操作系统的文件系统中，B+树的特点是能够保持数据稳定有序，其插入与修改拥有比较稳定的对数时间复杂度，B+树元素自底向上插入，这个和二叉树刚好相反。 B＋tree是一个n叉树，每个节点有多个叶子节点，一颗B+树包含根节点，内部节点，叶子节点。根节点可能是一个叶子节点，也可能是一个包含两个或两个以上叶子节点的节点。 B＋tree的性质： 1.n棵子tree的节点包含n个关键字，不用来保存数据而是保存数据的索引。 2.所有的叶子结点中包含了全部关键字的信息，及指向含这些关键字记录的指针，且叶子结点本身依关键字的大小自小而大顺序链接。 3.所有的非终端结点可以看成是索引部分，结点中仅含其子树中的最大(或最小)关键字。 由于B+tree的性质， 它通常被用于数据库和操作系统的文件系统中。NTFS, ReiserFS, NSS, XFS, JFS, ReFS 和BFS等文件系统都在使用B+树作为元数据索引，因为B+ 树的特点是能够保持数据稳定有序，其插入与修改拥有较稳定的对数时间复杂度(B+ 树元素自底向上插入)。 B＋tree结构原型图大概如下(引用)： 哈希表索引是怎么工作的？ 哈希表是另外一种你可能看到用作索引的数据结构-这些索引通常被称为哈希索引。使用哈希索引的原因是，在寻找值时哈希表效率极高。所以，如果使用哈希索引，对于比较字符串是否相等的查询能够极快的检索出的值。 哈希索引的缺点是什么呢？ 哈希表是无顺的数据结构，对于很多类型的查询语句哈希索引都无能为力。举例来说，假如你想要找出所有小于40岁的员工。你怎么使用使用哈希索引进行查询？这不可行，因为哈希表只适合查询键值对-也就是说查询相等的查询(例：like “WHERE name = ‘Jesus’)。哈希表的键值映射也暗示其键的存储是无序的。这就是为什么哈希索引通常不是数据库索引的默认数据结构-因为在作为索引的数据结构时，其不像B-Tree那么灵活 还有什么其他类型的索引？ 使用R-Tree作为数据结构的索引通常用来为空间问题提供帮助。例如，一个查询要求“查询出所有距离我两公里之内的星巴克”，如果数据库表使用R- Tree索引，这类查询的效率将会提高。 另一种索引是位图索引(bitmap index)， 这类索引适合放在包含布尔值(true 和 false)的列上，但是这些值(表示true或false的值)的许多实例-基本上都是选择性(selectivity)低的列。 二，索引内容 2.1、索引 索引是对数据库表中一列或者多列的值进行排序的一种结构，使用索引可以快速访问数据库表中的特定信息，索引有助于更快的获取信息。索引是表的目录，在查找内容之前可以先在目录中查找索引位置，以此快速定位查询数据。对于索引，会保存在额外的文件中。 索引的一个主要的目的就是加快检索表中数据的方法，也可以协助信息搜寻者能尽快的找到符合限制条件的记录。 2.2、索引种类 普通索引：仅加速查询 唯一索引：加速查询 + 列值唯一(可以有null) 唯一索引是不允许其中任何两行具有相同索引值的索引，当现有数据存在大量的重复的键值的时候，大多数数据库不允许唯一索引与表一起保存，数据库还可能防止添加将表中创建重复键值的新数据。 主键索引：加速查询 + 列值唯一 +　表中只有一个(不可以有null) 数据库表经常有一列或者多列组合，其值唯一标识表中的每一行，每一列称为表的主键，在数据库关系图中为表定义主键将自动创建主键索引，主键索引是唯一索引的特定类型，该索引要求主键索引的每个值都唯一。 组合索引：多列值组成一个索引， 专门用于组合搜索，其效率大于索引合并 全文索引：对文本的内容进行分词，进行搜索 ——普通索引 -1，创建表 + 索引 create table in1( nid int not null auto_increment primary key,

在nginx.conf配置文件中编辑 server { listen 80 default; listen 443 default_server; server_name _; return 403; ssl_certificate ***.pem; #随便找个pem ssl_certificate_key ***.pem; ssl_protocols TLSv1.1 TLSv1.2 TLSv1.3; ssl_ciphers EECDH+CHACHA20:EECDH+CHACHA20-draft:EECDH+AES128:RSA+AES128:EECDH+AES256:RSA+AES256:EECDH+3DES:RSA+3DES:!MD5; ssl_prefer_server_ciphers on; ssl_session_cache shared:SSL:10m; ssl_session_timeout 10m; }

用iconfont自带的批量去色功能解决 今天在使用 Symbol 代码引用图标时发现，设置颜色后，有一部分图标还是显示原始的颜色。原来这部分 svg图标带有 fill 属性，这种图标不能本地修改 fill 属性，需要在项目中移除默认颜色。

count函数是用来获取表中满足一定条件的记录数，常见用法有三种，count(*),count(1),count(field)，这三种有什么区别？在性能上有何差异？本文将通过测试案例详细介绍和分析。 三者有何区别： count(field)不包含字段值为NULL的记录。 count(*)包含NULL记录。 select(*)与select(1) 在InnoDB中性能没有任何区别，处理方式相同。官方文档描述如下： InnoDB handles SELECT COUNT(*) and SELECT COUNT(1) operations in the same way. There is no performance difference. 1. 性能对比 通过案例来测试一下count(*)，count(1)，count(field)的性能差异，MySQL版本为5.7.19，测试表是一张sysbench生成的表，表名sbtest1，总记录数2411645，如下： CREATE TABLE sbtest1 ( id int(11) NOT NULL AUTO_INCREMENT, k int(11) DEFAULT NULL, c char(120) NOT NULL DEFAULT '', pad char(60) NOT NULL DEFAULT '', PRIMARY KEY (id), KEY k_1 (k) ) ENGINE=InnoDB; 测试SQL语句： select count(*) from sbtest1; select count(1) from sbtest1; select count(id) from sbtest1;

count(*)对行的数目进行计算，包含NULL count(column)对特定的列的值具有的行数进行计算，不包含NULL值。 count()还有一种使用方式，count(1)这个用法和count(*)的结果是一样的。 任何情况下select count(*) from tablename是最优选择； 尽量减少select count(*) from tablename where COL = ‘value’这种查询； 杜绝select count(COL) from tablename where COL2 = ‘value’的出现。 如果表没有主键，那么count(1)比count(*)快。 如果有主键，那么count(主键，联合主键)比count(*)快。 如果表只有一个字段，count(*)最快。 count(1)跟count(主键)一样，只扫描主键。count(*)跟count(非主键)一样，扫描整个表。明显前者更快一些。 若含有where语句，则会优先where中条件索引。 原文：https://www.cnblogs.com/liuchunxiao83/p/11326348.html

使用情景 多个项目，一台图片存储服务器，方便做CDN 上传图片 <?php //上传用户商品图 $path = 'merchant/goods/'; $file = request()->file('up_img'); //创建一个 CURLFile 对象, 用与上传文件。filename上传文件的路径 mimetype文件的Mimetype postname文件名。 $cfile = curl_file_create($file->getInfo('tmp_name'), $file->getInfo('type'), str_replace('/', '_', $path)); $remote_data = [ 'file' => $cfile, 'post_data' => 'test' ]; $jsdata_url = 'http://cdn.img.abc.cn/upload.php'; $curl = curl_init(); curl_setopt($curl, CURLOPT_URL, $jsdata_url); curl_setopt($curl, CURLOPT_TIMEOUT, 30); curl_setopt($curl, CURLOPT_POST, 1); curl_setopt($curl, CURLOPT_RETURNTRANSFER, 1); curl_setopt($curl, CURLOPT_POSTFIELDS, $remote_data); $response = curl_exec($curl); curl_close($curl); if($response==400){ $this->ajaxReturn("上传失败!"); } else { return $response; } 存储图片 $file = $_FILES['file'];//图片文件 if (isset($file['type'])) { $type_arr = explode('/', $file['type']); } else { echo 400; exit; } $name= empty($file['name']) ?

CS即Client/Server(客户机/服务器)结构。 c代表客户端 s代表服务器，通过客户端和服务器进行通信的这类软件，叫c/s架构的软件，比如qq，微信，飞书等，一句话就是桌面应用程序。 特点： 1.要使用这种软件必须得安装 2.软件更新时，客户端和服务端都需要更新 3.c/s架构的软件不能跨平台 4.c/s架构通信采用的是自有协议（自己定义的协议），相对安全 B/S架构 b代表浏览器 s代表服务器，通过浏览器和服务器通信的软件，比如淘宝网，京东网，拼多多等，说白就是网站 特点： 1.使用这种软件不需要安装 2.软件更新时，客户端不需要更新，服务器肯定更新了 3.可以跨平台 4.HTTP协议，相对来说不安全

什么是漏洞？ 安全漏洞是信息系统在生命周期的各个阶段（设计，实现，运维等）产生的某一类问题，这些问题会对系统的安全（机密性，完整性，可用性）产生影响 漏洞和bug的关系是什么？ 漏洞不等于bug， BUG影响功能，不一定涉及安全性，不构成漏洞 大部分漏洞源于bug，漏洞和bug有一个交集 常见的web漏洞有哪些 SQL注入 （通过插入sql语句到参数中，让其后台sql服务器解析执行进行攻击） 变量类型分类 数字型（报错注入），字符型（盲注） HTTP提交方式分类 GET注入（布尔盲注），POST注入（时间盲注），Cookie注入（堆叠注入） SQL注入的危害 1.数据库信息泄露 2.网页篡改 3.网站挂马 4.数据库被恶意操作 5.服务器被远程控制 6.破坏硬盘数据 注：一些类型的数据库系统能让SQL指令操作文件系统，使SQL注入的危害被进一步放大 XSS漏洞 （Cross Site Scripting）跨站脚本攻击 防御措施：前端实体编码+后台特殊字符过滤 发生在用户端，发生了不可预期的JavaScript代码执行 分类：反射型XSS（非持久型XSS） 当用户访问一个带有XSS代码的URL请求时，服务器端接受数据后处理，然后把带有XSS代码的数据发生到浏览器，浏览器解析以后造成XSS漏洞 Payload：<img src=1 οnerrοr=alert(1)> 存储型XSS（持久型XSS） 允许用户存储数据的程序都可能出现存储型XSS，当攻击者提交代码以后被服务端接受并且存储，当再次访问时，被读取响应，造成XSS跨站攻击 DOM型XSS 与服务器解析响应无关系，是在javaScrip脚本动态执行的过程中产生 XSS漏洞的危害 1.网络钓鱼，盗取各类用户账号 2.窃取用户的cookie，获取用户隐私，利用用户身份进一步对网站执行操作 3.劫持用户会话，执行任意操作，非法转账，强制发表日志，发送电子邮件等 4.强制弹出广告页面，刷流量 5.网页挂马 6.进行恶意操作，任意篡改页面信息，删除文章 7.进行大量的客户端攻击，如DDOS攻击 8.获取客户端信息，例如用户的浏览历史，真实ip，开发端口等 9.控制受害者机器向其他网站发起攻击 10.结合其他的漏洞进一步扩大攻击 11.提升用户权限，包括进一步渗透网站 12.传播XSS跨站脚本蠕虫 。。。。。。。 XSS漏洞利用平台 https://github.com/samdenty/injectify https://github.com/s0md3v/JShell https://github.com/beefproject/beef CSRF漏洞（Cross-Site Request Forgery）也被称为One Click Attack 或者 Session Riding 与XSS不同 ，XSS利用站点内的信任用户，而CSRF则通过伪装来自受信任用户的请求来利用受信任的网站 简单理解，攻击者盗用你的身份，进行非法操作，比如修改密码，使用你的账户 登录网站A，B，网站B操作网站A 完成一次CSRF攻击 ，必须要满足两个步骤 1.受信任的网站A，在本地生成Cookie

Redis底层ZSet跳表是如何设计与实现的 跳表【skipList】其实就是有层级的列表。 比如我们想查找19，首先和6比较，大于6之后，在和9进行比较，然后在和12进行比较…最后比较到21的时候，发现21大于19，说明查找的点在17和21之间，从这个过程中，我们可以看出，查找的时候跳过了3、7、12等点。 参考博客：https://blog.csdn.net/ict2014/article/details/17394259Redis底层ZSet实现压缩列表和跳表如何选择 压缩列表：https://www.cnblogs.com/wujuntian/p/9129685.html 因为ziplist是紧凑存储，没有冗余空间，意味着新插入元素，就需要扩展内存：1. 分配新的内存，将原数据拷贝到新内存； 2. 扩展原有内存;所以ziplist 不适合存储大型字符串，存储的元素也不宜过多。 满足下面条件，zset、hash的底层存储结构不再是ziplist： hash-max-ziplist-entries 512 # hash 的元素个数超过 512 就必须用标准结构存储 hash-max-ziplist-value 64 # hash 的任意元素的 key/value 的长度超过 64 就必须用标准结构存储 zset-max-ziplist-entries 128 # zset 的元素个数超过 128 就必须用标准结构存储 zset-max-ziplist-value 64 # zset 的任意元素的长度超过 64 就必须用标准结构存储 Redis高并发场景热点缓存如何重建 热点key不设置过期时间，但是存在一个逻辑过期时间，逻辑过期时间保存在key相应 的value中 若发现逻辑过期时间到期，则返回老值，异步更新value值，存在的缺点会导致数据的短暂不一致 参考博客：https://blog.csdn.net/heima201907/article/details/10570065 高并发场景缓存穿透&失效&雪崩如何解决 缓存穿透: 布隆过滤缓存空对象. 将 null 变成一个值. .缓存雪崩 加锁排队. 限流-- 限流算法. 1.计数 2.滑动窗口 3. 令牌桶Token Bucket 4.漏桶 leaky bucket [1]数据预热做二级缓存，或者双缓存策略。缓存永远不过期: 从缓存上看，确实没有设置过期时间，这就保证了，不会出现热点key过期问题，也就是“物理”不过期。从功能上看，如果不过期，那不就成静态的了吗？所以我们把过期时间存在key对应的value里，如果发现要过期了，通过一个后台的异步线程进行缓存的构建，也就是“逻辑”过期. 参考博客：https://blog.csdn.net/fei33423/article/details/79027790 Redis集群架构如何抗住双十一的洪峰流量 这个没有找到合适的参考资料，我认为根据实际业务，去构建redis集群即可，保证redis有3个主节点，每个主节点至少有1个从节点。

注意JS来里面数组的sort（），直接排序是按照字符串进行排序的，对数字：arr.sort(function(a, b){return a - b}); var sortedSquares = function(arr) { var len = arr.length; var arr1 = []; for (var i = 0; i < len; i++){ arr1[i] = arr[i] * arr[i]; } arr1.sort(function(a, b){return a - b}); return arr1; };

学习目标： 目标：熟练运用 Java所学知识 题目内容： 本文内容： 使用Java实现：实现一个简单的控制台版用户登陆程序, 程序启动提示用户输入用户名密码. 如果用户名密码出错, 使用自定义异常的方式来处理 文章目录 学习目标：题目内容：简述+实现代码： 简述+实现代码： Java中虽然已经内置了丰富的异常类，但是我们实际场景中可能还有一些情况需要我们对异常类进行扩展，创建符合我们实际情况的异常 例如：我们实现一个用户登录功能 此时我们在处理用户名密码错误的时候可能就需要抛出两种异常，我们就需要对已有的异常进行扩展（继承），创建我们业务相关的异常类 //密码错误异常类 public class PasswordError extends Exception { public PasswordError(String message){ super(message); } } //用户名错误异常类 public class UserError extends Exception{ public UserError(String message){ super(message); } } import java.util.Scanner; public class RegisterException { private static String userName = "12345678"; private static String passerWord = "123456"; public static void main(String[] args) throws UserError, PasswordError { Scanner sc = new Scanner(System.

AspectJ5版本支持了基于注解的开发方式，当然其仍然需要AspectJ自己的编译器。 要使用基于注解的开发方式，需要为项目引入aspectjweaver.jar包，该Jar包也在AspectJ安装目录下的lib目录中。aspectjweaver.jar中包含了aspectjrt.jar包中的内容，所以只需要引入aspectjweaver.jar包即可。 1、创建类，在类里面定义方法 public class User { public void add() { System.out.println("add. "); } } 2、创建增强类（编写增强逻辑） 在增强类里面，创建方法，让不同方法代表不同通知类型 //增强的类 public class UserProxy { public void before() {//前置通知 System.out.println("before. "); } } 3、进行通知的配置 （1） 在 spring 配置文件中，开启注解扫描 <?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:context="http://www.springframework.org/schema/context" xmlns:aop="http://www.springframework.org/schema/aop" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context.xsd http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop.xsd"> <!-- 开启注解扫描 > <context:component-scan base- package="com.atguigu.spring5.aopanno"></context:component-scan> （2） 使用注解创建 User 和 UserProxy 对象 （3） 在增强类上面添加注解 @Aspect //增强的类 @Component @Aspect //生成代理对象 public class UserProxy { ） （4） 在 spring 配置文件中开启生成代理对象 <!