一切福田,不離方寸,從心而覓,感無不通。

html直接引用vue和element-ui的方法

代码如下所示:

效果如图: 总结 到此这篇关于html直接引用vue和element-ui的方法的文章就介绍到这了,更多相关html引用vue和element-ui内容请搜索脚本之家以前的文章或继续浏览下面的相关文章,希望大家以后多多支持脚本之家!   from:https://www.jb51.net/web/743299.html

龙生   24 Mar 2021
View Details

Kafka、RocketMQ、RabbitMQ的优劣势比较

最全MQ消息队列有哪些? 目前在业界有哪些比较知名的消息引擎呢?如下图所示 这里面几乎完全列举了当下比较知名的消息引擎,包括: ZeroMQ 推特的Distributedlog ActiveMQ:Apache旗下的老牌消息引擎 RabbitMQ、Kafka:AMQP的默认实现。 RocketMQ Artemis:Apache的ActiveMQ下的子项目 Apollo:同样为Apache的ActiveMQ的子项目的号称下一代消息引擎 商业化的消息引擎IronMQ 以及实现了JMS(Java Message Service)标准的OpenMQ。   MQ消息队列的技术应用 1.解耦 解耦是消息队列要解决的最本质问题。 2.最终一致性 最终一致性指的是两个系统的状态保持一致,要么都成功,要么都失败。 最终一致性不是消息队列的必备特性,但确实可以依靠消息队列来做最终一致性的事情。 2.广播 消息队列的基本功能之一是进行广播。 有了消息队列,我们只需要关心消息是否送达了队列,至于谁希望订阅,是下游的事情,无疑极大地减少了开发和联调的工作量。 3.错峰与流控 典型的使用场景就是秒杀业务用于流量削峰场景。 Kafka、RocketMQ、RabbitMQ比较   1.ActiveMQ 优点 单机吞吐量:万级 topic数量都吞吐量的影响: 时效性:ms级 可用性:高,基于主从架构实现高可用性 消息可靠性:有较低的概率丢失数据 功能支持:MQ领域的功能极其完备 缺点: 官方社区现在对ActiveMQ 5.x维护越来越少,较少在大规模吞吐的场景中使用。   2.Kafka 号称大数据的杀手锏,谈到大数据领域内的消息传输,则绕不开Kafka,这款为大数据而生的消息中间件,以其百万级TPS的吞吐量名声大噪,迅速成为大数据领域的宠儿,在数据采集、传输、存储的过程中发挥着举足轻重的作用。 Apache Kafka它最初由LinkedIn公司基于独特的设计实现为一个分布式的提交日志系统( a distributed commit log),之后成为Apache项目的一部分。 目前已经被LinkedIn,Uber, Twitter, Netflix等大公司所采纳。 优点 性能卓越,单机写入TPS约在百万条/秒,最大的优点,就是吞吐量高。 时效性:ms级 可用性:非常高,kafka是分布式的,一个数据多个副本,少数机器宕机,不会丢失数据,不会导致不可用 消费者采用Pull方式获取消息, 消息有序, 通过控制能够保证所有消息被消费且仅被消费一次; 有优秀的第三方Kafka Web管理界面Kafka-Manager; 在日志领域比较成熟,被多家公司和多个开源项目使用; 功能支持:功能较为简单,主要支持简单的MQ功能,在大数据领域的实时计算以及日志采集被大规模使用 缺点: Kafka单机超过64个队列/分区,Load会发生明显的飙高现象,队列越多,load越高,发送消息响应时间变长 使用短轮询方式,实时性取决于轮询间隔时间; 消费失败不支持重试; 支持消息顺序,但是一台代理宕机后,就会产生消息乱序; 社区更新较慢;   3.RabbitMQ RabbitMQ 2007年发布,是一个在AMQP(高级消息队列协议)基础上完成的,可复用的企业消息系统,是当前最主流的消息中间件之一。 RabbitMQ优点: 由于erlang语言的特性,mq 性能较好,高并发; 吞吐量到万级,MQ功能比较完备 健壮、稳定、易用、跨平台、支持多种语言、文档齐全; 开源提供的管理界面非常棒,用起来很好用 社区活跃度高; RabbitMQ缺点: erlang开发,很难去看懂源码,基本职能依赖于开源社区的快速维护和修复bug,不利于做二次开发和维护。 RabbitMQ确实吞吐量会低一些,这是因为他做的实现机制比较重。 需要学习比较复杂的接口和协议,学习和维护成本较高。 4.RocketMQ RocketMQ出自 阿里公司的开源产品,用 Java 语言实现,在设计时参考了 […]

龙生   19 Mar 2021
View Details

如何备份PostgreSQL数据库 常见的几个备份命令使用

一般我们建站使用较多的还是固定开源CMS程序,且基本上也使用的是PHP+MYSQL程序,所以数据库上较多的还是使用的MYSQL数据库。但是前几天老左有遇到一个网友他使用的是PostgreSQL数据库,实际上这个数据库我们在使用虚拟主机的时候也是有见过的,但是确实用的不多。 如果我们需要备份PostgreSQL数据库的话,一般如果我们服务器WEB环境自带的管理小工具是可以直接导出备份的,但是如果是运维工程师自己编译的WEB系统,那我们就需要用到其他的单独命令备份,这里我们记录下如何通过PostgreSQL命令备份数据库。 第一、一键快速备份单数据库 su – postgres 这里我们登陆数据库。 pg_dump laozuo.org > laozuo.org.bak 通过命令一键将我们的数据库名换成我们需要备份的,然后备份。这里我们可以将备份的数据下载到本地。 psql laozuo < dbname.bak 如果我们需要恢复数据库可以用psql命令来恢复,是不是有点像我们MYSQL恢复数据一样。 第二、远程备份数据库 一般远程备份数据库我们个人使用的不多的,我们还是老老实实在当前服务器操作比较多见,但是这里的方法老左也记录一下。 pg_dump -h 1.1.1.1 -p 1234 dbname > dbname.bak 根据命令及端口进行备份,注意数据库名修改成我们自己的。 第三、设置定时自动备份 这个我们很多朋友都有用的,一般项目文件动的不多,一般都是数据库在增减。所以我们定期备份数据库即可,但是我们需要做到的是定时备份。 1、登录数据库 su – postgres 和上面一样,我们要登录数据库,然后设置定时任务。 2、创建备份目录 mkdir -p ~/dbbackups 我们需要创建一个备份目录。 3、创建定时任务 crontab -e 然后需要编辑文件。 0 0 * * 0 pg_dump -U postgres laozuo> ~/dbbackups/laozuo.org.bak 编辑完毕保存后,我们运营一次看看,是否备份进入文件夹。 这里我们在备份完毕PostgreSQL数据库之后,我们还是需要定期下载或者SCP推送到其他服务器。之前有个朋友确实会定时备份,但是他备份到的还是自己当前服务器。于是前几天发现服务器故障数据丢失,他悲剧了。所以我们还是需要备份到本地。   from:https://www.laozuo.org/16772.html

龙生   19 Mar 2021
View Details

GIT更新远程分支列表

当本地和服务器上的远程列表不一致时,使用下面的命令更新: git remote update origin --prune git remote update origin -p   参考:https://blog.csdn.net/sd_csdn_scy/article/details/82025009

龙生   17 Mar 2021
View Details

说说 vue 父子组件加载顺序

面试提问:说说 vue 父子组件加载顺序 这我知道答案 父 beforeCreate 父 created 父 beforeMount 子 beforeCreate 子 created 子 beforeMount 子 mounted 父 mounted 子组件若有 props 的话更新顺序是四步,若无的话两步不触发父亲的钩子。 父 beforeUpdate 子 beforeUpdate 子 updated 父 updated 父组件更新顺序是 父 beforeUpdate 子 deactivated 父 updated 销毁过程是 父 beforeDestroy 子 beforeDestroy 子 destroyed 父 destroyed 再问,如果有多个子组件呢?我不太能确定。 加载多个子元素 回头写了一个简单的vue视图,父调用子,以下代码复制可用。

  控制台打印结果如下

  能得出结论,第一个子元素在 beforeMount 后不会直接 mounted,而是进入下一个子元素的 beforCreate。   from:https://www.cnblogs.com/everlose/p/12538472.html

龙生   15 Mar 2021
View Details

C#实现新建文件并写入内容

  from:https://www.cnblogs.com/thingk/p/3363880.html

龙生   11 Mar 2021
View Details

“git clone” 漏洞或可导致克隆过程中执行代码

近日,GitHub 官博披露了一个 “git clone” 命令的漏洞 CVE-2021-213,该漏洞可能导致特制的仓库在 git clone 过程中能够执行代码。 该漏洞源于 clean/smudge 过滤器(如Git LFS)中的延迟检查机制。 如果一个特别制作的版本库包含符号链接以及使用 clean/smudge 过滤器的文件,可能会导致在克隆到不区分大小写的文件系统(如 NTFS、HFS+ 或 APFS(即 Windows 和 macOS上 的默认文件系统))时执行刚检查出来的脚本。这个过程中,注意,clean/smudge 过滤器是必须的,而 Windows 默认配置了 Git LFS,因此更易受到攻击。2.15 到 2.30.1 的版本均会受到影响。 解决这个漏洞的最有效方法是升级到 2.30.2。如不能立即升级,也可以通过以下任何一种方式来降低风险: 通过运行 git config --global core.symlinks false 禁用 Git 中的符号链接支持。 禁用对进程过滤器的支持。(可以通过运行 git config --show-scope --get-regexp 'filter/\…*/\ process' 来查看系统是否配置了这些过滤器) 避免克隆不受信任的仓库。 GitHub 本身不容易受到这种攻击,因为其不会在服务器上存储已检查出的仓库副本,但 GitHub Pages 除外,尽管它没有使用任何 clean/smudge 过滤器。目前,该问题已在 3 月 9 日星期二发布的补丁中进行了修补。   from:https://www.oschina.net/news/132640/git-clone-vulnerability-cve-2021-213

龙生   11 Mar 2021
View Details

git修改之前某一个特定的commit

假如之前的某个提交的上一笔commit id是:928fc8a3686bf5fcf4527873e075703a9998c127

  然后在vi中修改pick为edit,wq保存退出,接着进行内容修改,git add后git commit --amend 最后git rebase --continue即可再次回到最新的头部 作者:一只特例独行de猪 链接:https://www.jianshu.com/p/96ed16586a86 来源:简书 著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

龙生   10 Mar 2021
View Details

CBC模式和ECB模式解读

一 什么是CBC模式 CBC模式的全称是Cipher Block Chaining模式(密文分组链接模式),之所以叫这个名字,是因为密文分组像链条一样相互连接在一起。 在CBC模式中,首先将明文分组与前一个密文分组进行XOR运算,然后再进行加密。 CBC模式加解密过程如下:      我们来比较一下ECB模式与CBC模式的区别    ECB模式只进行了加密,而CBC模式则在加密之前进行了一次XOR。 二 初始化向量 当加密第一个明文分组时,由于不存在“前一个密文分组”,因此需要事先准备一个长度为一个分组的比特序列来代替“前一个密文分组”,这个比特序列称为初始化向量(Initialization Vector),通常缩写为IV,一般来说,每次加密时都会随机产生一个不同的比特序列来作为初始化向量。 三 CBC模式的特点 明文分组在加密之前一定会与“前一个密文分组”进行XOR运算,因此即使明文分组1和明文分组2的值是相等的,密文分组1和2的值也不一定是相等的。这样一来,ECB模式的缺陷在CBC模式中就不存在了。 加密过程:在CBC模式中,无法单独对一个中间的明文分组进行加密。例如,如果要生成密文分组3,则至少需要凑齐明文分组1、2、3才行。 解密过程:假设CBC模式加密的密文分组中有一个分组损坏了。在这种情况下,只要密文分组的长度没有发生变化,则解密时最多只有2个分组受到数据损坏的影响。见下图:    假设CBC模式的密文分组中有一些比特缺失了,那么此时即便只缺失1比特,也会导致密文分组的长度发生变化,此后的分组发生错位,这样一来,缺失比特的位置之后的密文分组也就全部无法解密。见下图:    四 对CBC模式的攻击 假设主动攻击者的目的是通过修改密文来操纵解密后的明文。如果攻击者能够对初始化向量中的任意比特进行反转(将1变成0,将0变成1),则明文分组中相应的比特也会被反转。这是因为在CBC模式的解密过程中,第一个明文分组会和初始化向量进行XOR运算。见下图。    但是想对密文分组也进行同样的攻击就非常困难了。例如,如果攻击者将密文分组1中的某个比特进行反转,则明文分组2中相应比特也会被反转,然而这一比特的变化却对解密后的明文分组1中的多个比特造成了影响,也就是说,只让明文分1中所期望的特定比特发生变化是很困难的。 五 填充提示攻击 填充提示攻击是一种利用分组密码中填充部分来进行攻击的方法。在分组密码中,当明文长度不为分组长度的整数倍时,需要在最后一个分组中填充一些数据使其凑满一个分组长度。在填充提示攻击中,攻击者会反复发送一段密文,每次发送时都对填充数据进行少许改变。由于接收者(服务器)在无法正确解密时会返回一个错误消息,攻击者通过这一错误消息就可以获得一部分与明文相关的信息。这一攻击并不仅限于CBC模式,而是适用所有需要进行分组填充的模式。 2014年对SSL3.0 造成了重大影响POODLE攻击实际上就是一种填充示攻击。 六 对初始化向量(IV)进行攻击 初始化向量(IV)必须使用不可预测的随机数。然而在SSL/TLS的TLS1.0版本协议中,IV并没有使用不可预测的随机数,而是使用上一次CBC模式加密时的最后一个分组。为了防御攻击者对此进行攻击,TLS1.1以上的版本中改为了必须显示传送IV。 七 CBC模式应用 确保互联网安全的通信协议之一SSL/TLS,就是使用CBC模式来确保通信机密性的,如使用CBC模式三重DES的3DES_EDE_CBC以及CBC模式256比特AES的AES_256_CBC等。 ———————————————— 版权声明:本文为CSDN博主「cakincqm」的原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接及本声明。 原文链接:https://blog.csdn.net/chengqiuming/article/details/82288851 from:https://www.cnblogs.com/wangle1001986/p/11468419.html

龙生   08 Mar 2021
View Details