神奇四侠

当对语音的响度进行调整的需要时，就要做语音自动增益（AGC）算法处理，语音聊天时都会用到这个算法。 最简单的硬性增益处理是对所有音频采样乘上一个增益因子，它也等同于在频域每个频率都同时乘上这个增益因子，但由于人的听觉对所有频率的感知不是线性的，是遵循等 响度曲线的，导致这样处理后，听起来感觉有的频率加强了，有的频率削弱了，导致语言失真的放大。 要让整个频段的频率听起来响度增益都是“相同”的，就必须在响度这个尺度下做增益，而不是在频率域，即按照等响度曲线对语音的频率进行加权，不能采用一个固定的增益 因子进行加权。 由些可见，语音的自动增益处理可以大致分为两个部分： （1）响度增益因子的确定。 （2）把响度增益因子映射到等响度曲线上，确定最终各频率的增益权重。 ---------------------

像中的3A控制是指自动曝光控制(AE)、自动聚焦控制(AF)、自动白平衡控制(AWB)。自动曝光控制能够自动调节图像的明暗度，自动聚焦控制能够自动调节图像的焦距，自动白平衡能够使得图像成像在经典光源下的颜色. 自动聚焦（Automatic Focus）: 自动聚焦的方法可以按下图分类： ( 1 )红外线测距法的原理是由照相机主动发射红外线作为测距光源 ，并由红外发光二极管间构成的几何关系计算出对焦距离。 ( 2 )超声波测距法是根据超声波在相机和被摄物之间传播的时间进行测距的。相机上分别装有超声波的发射和接收装置，工作时由超声振动发生器发出持续超声波。超声波到达被摄体后立即返回被接收器感知，然后由集成电路根据超声波的往返时间来计算确定对焦距离。 自动聚焦的过程就是对成像清晰度评价的过程：对焦不准确则拍摄出来的图像清晰度低；对焦准确则图像清晰度较高，对比度高。 图像清晰度评价算法有多种：空域中，主要是考察图像的邻域对比度，即相邻像素的灰度梯度差；频域中，主要是考察图像的频率分量，对焦清晰的图像高频分量较多。清晰度评价方法包括Tenengrad梯度法、Laplacian梯度法、方差法和能量熵等方法，其中Tenengrad梯度法可以用sober算子近似代替；方差大表示一组数据之间的偏差就大，对焦清晰的图像相比对焦模糊的图像数据之间的灰度差异应该更大，即方差较大，可以通过图像灰度数据的方差来衡量图像的清晰度，方差越大，表示清晰度越好。     Mat imageSource = imread("...");      Mat imageGrey;       cvtColor(imageSource, imageGrey, CV_RGB2GRAY);      Mat imageSobel;      Sobel(imageGrey, imageSobel, CV_16U, 1, 1);   //Sobel换为Laplacian，即为Laplacian梯度值     //meanValue近似代替Teneng...

redis作为缓存型数据库，越来越受到大家的欢迎，这里简单介绍一下java如何操作redis。 1、java连接redis java通过需要jedis的jar包获取Jedis连接。   jedis-2.8.0.jar     public void getConn()     {         //获取jedis连接         Jedis jedis = new Jedis("127.0.0.1",6379);         //获取redis中以FIELD开头的key         Set<String> keys = jedis.keys("FIELD*");         for(String key : keys)         {             System.out.println(key);         }     } 2、java获取jedis连接池 如果每次连接redis都new1个Jedis的话，势必耗费很多资源，这里就提到redis连接池。 所需jar包 commons-pool2-2.3.jar jedis-2.8.0.jar     public class RedisUtil     {         private static JedisPool pool = null; ...

关于redis主从、哨兵、集群的介绍网上很多，这里就不赘述了。 一、主从     通过持久化功能，Redis保证了即使在服务器重启的情况下也不会损失（或少量损失）数据，因为持久化会把内存中数据保存到硬盘上，重启会从硬盘上加载数据。     。但是由于数据是存储在一台服务器上的，如果这台服务器出现硬盘故障等问题，也会导致数据丢失。为了避免单点故障，通常的做法是将数据库复制多个副本以部署在不同的服务器上，这样即使有一台服务器出现故障，其他服务器依然可以继续提供服务。为此， Redis 提供了复制（replication）功能，可以实现当一台数据库中的数据更新后，自动将更新的数据同步到其他数据库上。     在复制的概念中，数据库分为两类，一类是主数据库（master），另一类是从数据库[1] （slave）。主数据库可以进行读写操作，当写操作导致数据变化时会自动将数据同步给从数据库。而从数据库一般是只读的，并接受主数据库同步过来的数据。一个主数据库可以拥有多个从数据库，而一个从数据库只能拥有一个主数据库。     主从数据库的配置     master  slave     主不用配置，从redis的conf文件加入 slaveof ip port 就可以了     或者从redis启动时  redis-server --port 6380 --slaveof 127.0.0.1 6379         从数据库一般是只读，可以改为可写，但写入的数据很容易被主同步没，所以还是只读就可以。     也可以在运行是使用slaveof ip port命令，停止原来的主，切换成刚刚设置的主  slaveof no one会把自己变成主     复制原理     当从数据库启动时，会向主数据库发送sync命令，主数据库接收到sync后开始在后台报错快照rdb，在保存快照期间受到的命名缓存...

Redis的定位还是分布式缓存，关于分布式的特点和挑战这里不再介绍。 一、 Redis主从模式的必要性     备份数据：当一个节点损坏时，数据因为有备份，可以方便恢复。     负载均衡：避免所有客户端都访问一个节点，有了主从模式后，查询操作就可以通过查询从节点来完成。 二、Redis主从模式的特点：     一个Master可以有多个Slaves     默认配置下，master节点可以进行读和写，slave节点只能进行读操作，写操作被禁止     不要修改配置让slave节点支持写操作，没有意义，因为，首先写入的数据不会被同步到其他节点，其次，当master节点修改同一条数据后，slave节点的数据会被覆盖掉     slave节点挂了不影响其他slave节点的读和master节点的读和写，重新启动后会将数据从master节点同步过来     master节点挂了以后，不影响slave节点的读，Redis将不再提供写服务，master节点启动后Redis将重新对外提供写服务。     master节点过了以后，不会从slave节点中重新选一个master。     对由密码的情况说明：当master节点设置密码时：     * 客户端访问master需要密码；     * 启动slave需要密码，在配置中进行配置即可；     * 客户端访问slave不需要密码 三、Redis主从模式的缺点：     master节点挂了以后，redis就不会对外提供写服务了，因为剩下的slave节点不会成为master     所以生产环境不会单单只有主从模式。 四、 搭建Redis主从模式： 1. 准备本机redis集群环境 参看：https://blog.csdn.net/xiaoxiaoyusheng2012/article/details/82051744...

一次呢我们讲到了redis的集群，还有redis的主从复制，读写分离的一些配置，那么接下来就接着上次还未完结的内容 上一次呢讲的是在正常的情况下redis服务在各个主机上的运行情况，那么接下来就是要介绍不正常的情况了。 假如说我们的redis的主库挂了或者是运行redis服务的服务器挂了，那么其余的redis从库是否会趁机上位还是忠于职守在slave的角色？那么接下来就为大家揭晓 首先启动redis服务，包括主库与从库 这里写图片描述 各个服务器上的redis服务均启动正常，那么接下来就是模拟redis主库宕机了 shutdown表示关闭redis服务 exit表示退出redis连接 这里写图片描述 那么接下来就是查看各个redis从库的角色以及连接状态了 这里写图片描述 我们可以看到，在从库中还是可以拿到数据的，说明redis主库挂了并不会影响redis从库的运行。但是看到master_line_status为down的时候，就知道这个时候的主库是挂了的，因为一开始的状态是up 那么如果redis主库的服务有重新启动了呢？redis从库会不会再次连接上主库？ 这里写图片描述 首先启动redis主库，然后写入数据，这个时候发现从库的master_line_status的连接状态都是up了，并且可以取到在redis主库中写入的数据 那么这样子是不是很不好啊，假如是电商网站，然后突然间redis主库挂了，那么这个时候就只有redis从库服务在运行了。但是redis从库是只读的是不是就无法写入数据了，那么客户就无法下订单了。那么有没有什么方法，就是在redis主服务挂了之后我再从redis从库服务中挑选出一个比较优秀的来接替主库的位置 方案一：使用命令的方式 那么接下来呢我们就学习一个新的命令     slaveof no one 这里写图片描述 可以看到，命令执行之后，就立刻趁机上位了，那么另外一台从库是不是也要换一个新的老大啊 这里写图片描述 但是这个时候原来的redis主库有杀回来了呢？这个时候是不是另外两个就是有两个redis主库的服务了，但是原来的从库并不会回到这个主库上去，而是后面那两台自立规则。那么这个时候是不是很不好啊，我们想要的是只有一个redis主库服务，那么有没有什么解决方法呢？ 那么接下来就是终极的解决方案 方案二：哨兵...

1.主备切换的过程，可能会导致数据丢失 因为master -> slave的复制是异步的，所以可能有部分数据还没复制到slave，master就宕机了，此时这些部分数据就丢失了 2.脑裂导致的数据丢失 脑裂，也就是说，某个master所在机器突然脱离了正常的网络，跟其他slave机器不能连接，但是实际上master还运行着，此时哨兵可能就会认为master宕机了，然后开启选举，将其他slave切换成了master，这个时候，集群里就会有两个master，也就是所谓的脑裂，此时虽然某个slave被切换成了master，但是可能client还没来得及切换到新的master，还继续向旧master写数据，此时有可能也丢失了，因此旧master再次恢复的时候，会被作为一个slave挂到新的master上去，自己的数据会清空，重新从新的master复制数据 减少数据丢失的配置： min-slaves-to-write 1 min-slaves-max-lag 10 要求至少有1个slave，数据复制和同步的延迟不能超过10秒，如果说一旦所有的slave，数据复制和同步的延迟都超过了10秒钟，那么这个时候，master就不会再接收任何请求了 有了min-slaves-max-lag这个配置，就可以确保说，一旦slave复制数据和ack延时太长，就认为可能master宕机后损失的数据太多了，那么就拒绝写请求，这样可以把master宕机时由于部分数据未同步到slave导致的数据丢失降低到可控范围内   如果一个master出现了脑裂，跟其它的slave丢失连接，那么这两个配置可以确保，如果不能继续给指定数量的slave发送数据，而且slave超过10秒没有给自己ack消息，那么就直接拒绝客户端的写请求，这样脑裂后的旧master就不会接受client的新数据，也就避免了数据丢失，因此在脑裂场景下，最多就丢失10秒的数据 在此我向大家推荐一个架构学习交流群。交流学习群号：938837867 暗号：555 里面会分享一些资深架构师录制的视频录像：有Spring，MyBatis，Netty源码分析，高并发、高性能、分布式、微服务架构的原理，JVM性能优化、分布式架构等这些成为架构师必备 ---------------------

主从复制主要用途： 1.灾备切换 2.读写分离 3.备份，避免影响业务 4.高可用和故障切换 5.mysql测试升级 首先，异步主从复制主要步骤： 1.主库中开启log_bin 2.全备份主库 3.授权（grant replication slave on . ） 4.配置复制，并启动（change master to） 5.查看主从复制信息 异步主从复制存在的主要问题： 1.主机宕机后，数据可能丢失 2.从库只有一个sql thread，当主库有大量写入时候，从库容易丢失数据 异步复制的演示： 第一步：主库中开启log_bin=1,在my.cnf文件中设置，这里就不详细介绍了。 第二步：用mysqldump进行主库全备份 [root@VM_85_42_centos downloads] # ps -ef |grep mysqld #查看配置位置 root 5307 1 0 Apr03 ? 00 : 00 : 00 /bin/sh /usr/local/mysql56/bin/mysqld_safe --defaults-file= /mysqldata/my .cnf mysql 5539 5307 0 Apr03 ? 00 : 00 : 50 /usr/local/mysql56/bin/mysqld --defaults-file= /mysqldata/my .cnf --basedir= /usr/local /mysql56 --datadir=/mysqldata /node1 --plugin-dir=/usr /local/mysql 56/lib/plugin --user=mysql --log-error= /mysqldata/node 1/VM_85_42_centos.err --pid-file= /mysqldata/node 1/VM_85_42_centos.pid --socket= /tmp/mysql .sock --port= 6000 root 13332 20569 0 23 : 19 pts/ 0 00 : 00 : 00 grep --color=aut...

这里虽然说的是Mysql数据库，但对应其他数据库，原理没有什么差异。只是在具体实现和配置上不同。 一、异步复制（Asynchronous replication） 1、逻辑上 MySQL默认的复制即是异步的，主库在执行完客户端提交的事务后会立即将结果返给给客户端，并不关心从库是否已经接收并处理，这样就会有一个问题，主如果crash掉了，此时主上已经提交的事务可能并没有传到从库上，如果此时，强行将从提升为主，可能导致新主上的数据不完整。 2、技术上 主库将事务 Binlog 事件写入到 Binlog 文件中，此时主库只会通知一下 Dump 线程发送这些新的 Binlog，然后主库就会继续处理提交操作，而此时不会保证这些 Binlog 传到任何一个从库节点上。 二、全同步复制（Fully synchronous replication） 1、逻辑上 指当主库执行完一个事务，所有的从库都执行了该事务才返回给客户端。因为需要等待所有从库执行完该事务才能返回，所以全同步复制的性能必然会收到严重的影响。 2、技术上 当主库提交事务之后，所有的从库节点必须收到、APPLY并且提交这些事务，然后主库线程才能继续做后续操作。但缺点是，主库完成一个事务的时间会被拉长，性能降低。 三、半同步复制（Semisynchronous replication） 1、逻辑上 是介于全同步复制与全异步复制之间的一种，主库只需要等待至少一个从库节点收到并且 Flush Binlog 到 Relay Log 文件即可，主库不需要等待所有从库给主库反馈。同时，这里只是一个收到的反馈，而不是已经完全完成并且提交的反馈，如此，节省了很多时间。 2、技术上 介于异步复制和全同步复制之间，主库在执行完客户端提交的事务后不是立刻返回给客户端，而是等待至少一个从库接收到并写到relay log中才返回给客户端。相对于异步复制，半同步复制提高了数据的安全性，同时它也造成了一定程度的延迟，这个延迟最少是一个TCP/IP往返的时间。所以，半同步复制最好在低延时的网络中使用。 四、选型及设置说明 如何设置到相应的同步方式上呢？ mysql主从模式默认是异步复制的，而MySQL Cluster是同步复制的，只要设置为相应的模式即是在使用相应的同步策略。 从MySQL5.5开始，MySQL以插件的形式支持半同步复制。其实说明半同...

一、MySQL异步复制介绍 1. 复制的用途 2. 复制如何工作 3. 两阶段提交 二、复制实验环境 三、安装mysql-8.0.16 四、配置异步复制 1. 空库 2. 脱机 3. 联机 一、MySQL异步复制介绍         简单说，复制就是将来自一个MySQL数据库服务器（主库）的数据复制到一个或多个MySQL数据库服务器（从库）。传统的MySQL复制提供了一种简单的Primary-Secondary复制方法，默认情况下，复制是单向异步的。MySQL支持两种复制方式：基于行的复制和基于语句的复制。这两种方式都是通过在主库上记录二进制日志（binlog）、在从库重放中继日志（relylog）的方式来实现异步的数据复制。二进制日志或中继日志中的记录被称为事件。所谓异步包含两层含义，一是主库的二进制日志写入与将其发送到从库是异步进行的，二是从库获取与重放日志事件是异步进行的。这意味着，在同一时间点从库上的数据更新可能落后于主库，并且无法保证主从之间的延迟间隔。         复制给主库增加的开销主要体现在启用二进制日志带来的I/O，但是开销并不大，MySQL官方文档中称开启二进制日志会产生1%的性能损耗。出于对历史事务备份以及从介质失败中恢复的目的，这点开销是非常必要的。除此之外，每个从库也会对主库产生一些负载，例如网络和I/O开销。当从库读取主库的二进制日志时，可能会造成一定的I/O开销。如果从一个主库上复制到多个从库，唤醒多个复制线程发送二进制日志内容的开销将会累加。但所有这些复制带来的额外开销相对于应用对MySQL服务器造成的高负载来说是很小的。 1. 复制的用途 （1）横向扩展         通过复制可以将读操作指向从库来获得更好的读扩展。所有写入和更新都在主库上进行，但读取可能发生在一个或多个从库上。在这种读写分离模型中，主库专用于更新，显然比同时进行读写操作会有更好的写性能。需要注意的是，对于写操作并不适合通过复制来扩展。在一主多从架构中，写操作会被执行多次，这时整个系统的写性能取决于写入最慢的那部分。 （2）负载均衡  ...