update

前面的话 　　如果想与他人使用，除了使用Git来完成日常工作之外，还需要一个远程的Git仓库。尽管从技术上可以从个人的仓库里推送和拉取修改内容，但并不鼓励这样做，因为一不留心就很容易弄混其他人的进度。因此，更好的合作方式是建立一个大家都可以访问的共享仓库，从那里推送和拉取数据。我们将这个仓库称为"Git服务器"；代理一个Git仓库只需要花费很少的资源，几乎从不需要整个服务器来支持它的运行 　　远程仓库通常只是一个裸仓库(bare repository)——即一个没有当前工作目录的仓库。因为该仓库只是一个合作媒介，所以不需要从硬盘上取出最新版本的快照；仓库里存放的仅仅是Git的数据。简单地说，裸仓库就是你工作目录中.git子目录内的内容 　　本文将详细介绍服务器上的Git 协议 　　Git可以使用四种主要的协议来传输数据：本地传输，SSH协议，Git协议和HTTP协议。下面分别介绍一下哪些情形应该使用(或避免使用)这些协议 　　值得注意的是，除了HTTP协议外，其他所有协议都要求在服务器端安装并运行Git 【本地协议】 　　最基本的就是本地协议(Local protocol)，所谓的远程仓库在该协议中的表示，就是硬盘上的另一个目录。这常见于团队每一个成员都对一个共享的文件系统(例如NFS)拥有访问权，或者比较少见的多人共用同一台电脑的情况。后面一种情况并不安全

我觉得自己写的不好，所以先贴一个写的好的帖子 感觉看完不用回来了。。。。 这是一个大佬写的的博客 : https://www.cnblogs.com/yixianyixian/p/8372832.html 第一：JavaEE 体系进行分层开发，事务处理位于业务层，Spring 提供了分层设计 业务层 的事务处理解决方 案。 第二：spring 框架为我们提供了一组事务控制的接口。具体在后面的第二小节介绍。这组接口是在 spring-tx-5.0.2.RELEASE.jar 中。 第三：spring 的事务控制都是基于 AOP 的，它既可以使用编程的方式实现，也可以使用配置的方式实现。我 们学习的重点是使用配置的方式实现。 API 介绍 PlatformTransationManager Spring提供了一个事务管理器接口 PlatformTransationManager ,该接口包含了三个方法: getTransation()//提交事务 commit();//提交事务 rollback();//回滚事务 在开发中，根据应用的技术不同，使用不同的实现类 SpringJDBC / iBatis：org.springframework.jdbc.datasource. DataSourceTransactionManager Hibernate：org

当在现实生活中的遇到问题时，我们总是希望找到最佳的解决方案。制造软件产品也是一样的道理，最优化的程序才是最理想的产品。 最优化意味着获得最佳输出。它既是一个数学的重要分支，也在现实生活中有着重要的作用。现代的计算机科学和人工智能科学把最优化作为一个重要的领域来研究。我们也认为人工智能的一些算法，就是模拟了人类寻求实际问题最优解的过程。例如，利用人工智能算法设计软件，配合外部的电子设备例如摄像头识别人脸；利用数据挖掘和神经网络算法来寻找投资的最佳时机等等，都是利用了最优化的原理。 机器学习中的最优化和其他学科的应用比起来有轻微的差异。一般来说，在优化的同时，我们确切地知道数据的外观以及我们想要改进的地方。 但是在机器学习中，我们不知道“新数据”是怎么样的，更别提对其进行优化了。为了解决这个问题，在机器学习中，我们对训练数据（training data）执行优化，并检查由此新创造出的验证数据（validation data）。 最优化的广泛应用 机械学：设计航空航天产品的表面； 经济学：成本最小化； 物理学：量子计算中的优化时间； 决定最佳运输路线，货架空间优化等等。 许多流行的机器算法都依赖于线性回归，k最近邻，神经网络等技术。优化的应用是无限的，因此它成为了学术界和工业界广泛研究的课题。在本文中，我们将介绍一种称为梯度下降（Gradient Descent）的优化技术。

原文链接： http://www.yiidian.com/mybatis/mybatis-dao.html 在MyBatis中，我们有两种Dao的写法，一种叫传统Dao写法，一种叫Mapper代理接口。下面看看如何实现。 1 传统Dao写法 1.1 编写CustomerDao接口 package com.yiidian.dao; import com.yiidian.domain.Customer; import java.util.List; /** * Dao接口 *一点教程网 - www.yiidian.com */ public interface CustomerDao { /** * 查询所有用户 */ public List<Customer> findAll(); /** * 添加 */ public void save(Customer customer); /** * 修改 */ public void update(Customer customer); /** * 查询一个 */ public Customer findById(Integer id); /** * 条件查询 */ public List<Customer> findByName(String name); /** * 删除 */ public void delete(Integer id)

第一种： 登入后台，找到所使用主题的function.php，在任意空白处加上下面两行代码： update_option('siteurl','http://zhuangxiu.dog'); update_option('home','http://zhuangxiu.dog'); 然后覆盖原文件即可，再次登录，完全恢复正常！最后把原文件再修改过来，欧了~~ 第二种： 解决方法： 1、登陆phpMyAdmin，选中你的WordPress数据库； 2、找到wp-options这个数据表； 3、打开这个表，找到第一条记录，也就是option_name为siteurl的那条记录，将option_value中错误的地址改为正确的即可。（如果option_name为home的那条记录地址也是错误的，改为正确的即可） 来源： https://www.cnblogs.com/housestudy/p/12585680.html

问题 最近项目中遇到了一个分布式系统的并发控制问题。该问题可以抽象为：某分布式系统由一个数据中心D和若干业务处理中心L1，L2 ... Ln组成；D本质上是一个key-value存储，它对外提供基于HTTP协议的CRUD操作接口。L的业务逻辑可以抽象为下面3个步骤： read: 根据keySet {k1, ... kn}从D获取keyValueSet {k1:v1, ... kn:vn} do: 根据keyValueSet进行业务处理，得到需要更新的数据集keyValueSet' {k1':v1', ... km':vm'} ( 注 ：读取的keySet和更新的keySet'可能不同) update: 把keyValueSet'更新到D （ 注 ：D保证在一次调用更新多个key的原子性） 在没有事务支持的情况下，多个L进行并发处理可能会导致数据一致性问题。比如，考虑L1和L2的如下执行顺序： L1从D读取key:123对应的值100 L2从D读取key:123对应的100 L1对值增加1，将key:123更新为100 + 1 L2对值增加2，将key:123更新为100 + 2 如果L1和L2串行执行，key:123对应的值将为103，但上面并发执行中L1的执行效果完全被L2所覆盖，实际key:123所对应的值变成了102。 解决方案1：锁机制 为了让L的处理可串行化

创建一个连接引擎 engine=create_engine( "mysql+pymysql://root:password@localhost:3306/test",echo= True) from sqlalchemy import func, or_, not_ user = User(name='a') session.add(user) user = User(name='b') session.add(user) user = User(name='a') session.add(user) user = User() session.add(user) session.commit() query = session.query(User) print query # 显示SQL 语句 print query.statement # 同上 for user in query: # 遍历时查询 print user.name print query.all() # 返回的是一个类似列表的对象 print query.first().name # 记录不存在时，first() 会返回 None # print query.one().name # 不存在，或有多行记录时会抛出异常 print query.filter(User.id == 2).first().name

BGP邻居建立过程 BGP（Border Gateway Protocol）是一种用于自治系统（Autonomous System）之间的动态路由协议。BGP使用TCP作为其传输层协议（监听端口号为179）。 BGP对等体间通过以下5种报文进行交互，其中Keepalive报文为周期性发送，其余报文为触发式发送： • Open报文：用于建立BGP对等体连接。 • Update报文：用于在对等体之间交换路由信息。 • Notification报文：用于中断BGP连接。 • Keepalive报文：用于保持BGP连接。 • Route-refresh报文：用于在改变路由策略后请求对等体重新发送路由信息。只有支持路由刷新（Route-refresh）能力的BGP设备会发送和响应此报文。 Open报文： 是TCP连接建立后发送的第一个报文，用于建立BGP邻居之间的连接关系。BGP邻居在接收到Open报文并协商成功后，将发送Keepalive报文确认并保持连接的有效性。确认后，BGP邻居间可以进行Update、Notification、Keepalive和Route-refresh报文的交换。 Keepalive报文： BGP路由器会周期性的向邻居发出Keepalive报文，用来保持连接的有效性。 Update报文： 用于在BGP邻居之间交换路由信息

并发控制 并发情况下，需要做一些控制（一般是加锁），保证共享数据的一致性。 并发操作数据库时，需要给数据库中的数据加锁，确保数据库中数据的一致性。 数据库锁的常见分类 按使用方式来分：悲观锁、乐观锁 按锁级别来分：共享锁、排它锁（主要是这2种，当然还有其他的） 按锁粒度来分：行级锁、表级锁、页级锁 悲观锁 Pessimistic Lock 悲观的，假设是最坏的情况，认为其它线程一定会修改当前线程使用的数据库数据，当前线程一定要给使用的数据库数据加锁。 悲观锁只是个统称，并不是指某一种具体的锁。悲观锁主要包括： 共享锁（S锁，share），又称为读锁，所有线程都可以访问，但都只能读 排它锁（X锁），又称为写锁，是排它的，同一时刻只能有一个线程来访问，这个线程可对加锁的数据进行读写。 Java中的 synchronized、 ReentrantLock 等独占锁就是悲观锁思想的实现。 悲观锁一般要借助数据库本身提供的锁机制来实现。 以mysql最常用的InnoDB引擎为例：加排它锁 begin; //开始事务 select * from tb_user where id=1 for update; //给选中的行加锁 update tb_user set username='chy',password='abcd' where id=1; //修改数据 commit; //提交事务

CVE编号: CVE-2019-3862 修复命令： yum update libssh2 影响说明 软件： libssh2 1.4.3-12.el7_6.2 命中： libssh2 version less than 0:1.4.3-12.el7_6.3 路径： /usr/lib64/libssh2.so.1 CVE编号：CVE-2018-14618 修复命令： yum update libcurl yum update curl 影响说明 软件： libcurl 7.29.0-51.el7 命中： libcurl version less than 0:7.29.0-51.el7_6.3 路径： /usr/lib64/libcurl.so.4 软件： curl 7.29.0-51.el7 命中： curl version less than 0:7.29.0-51.el7_6.3 路径： /usr/bin/curl CVE编号：CVE-2019-10160 修复命令： yum update python-devel yum update python-libs yum update python 影响说明 软件： python-devel 2.7.5-77.el7_6 命中： python-devel version less than 0:2.7.5-80.el7_6 路径：