Redis

由于直播的市场越发火热，不同的直播模式也在不断发生变化，尤其是目前比较多的一对一直播，其软件在开发上需要满足用户的私密性和其他功能，那么对于这种直播开发的功能和系统是什么，我们来了解一下。   首先来了解一下一对一直播软件的系统开发语言：  一对一直播源码 后台PHP语言 Android是Java语言 IOS是直播系统前端APP是分成安卓端和苹果端。后端是PC端，控制前端的。APP是原生开发的。 PHP 视频互动系统由 WEB 系统、REDIS 服务、MYSQL 服务、视频服务、聊天服务、后台管理系统和定时监控组成，手机端安卓开发语言采用：java、 IOS 苹果采用：原生开发，后台管理采用PHP 语言开发，所有服务提供横向扩展。含app双端，web后台。  一对一直播的功能有哪些？  做直播社交和互动性是必不可少的，一对一直播互动性更强，主播只需与一个观众互动，相对来说也轻松不少；  私密性，一对一的形式更具私密性，内容只有主播和观众知道，后台起到监管作用，能够带来更加优质的内容；  收益，一对多的直播并不是所有的观众都会进行打赏，但是一对一采用的是计时收费，同样可以打赏主播，有的功能则需要充值VIP才能使用，间接就增加了主播和观众的收益。    私信功能是比不可少的，当主播在于他人直播的时候，能够发送私信，可提前预定主播，同时也可以联系主播，而私信也可以设置收费，增加收益； 

集成的客户端 1）lettuce方式集成 <dependency> <groupId>org.apache.commons</groupId> <artifactId>commons-pool2</artifactId> </dependency> <dependency> <groupId>io.lettuce</groupId> <artifactId>lettuce-core</artifactId> </dependency> <dependency> <groupId>org.springframework.data</groupId> <artifactId>spring-data-redis</artifactId> </dependency> 2） jedis方式集成 <dependency> <groupId>redis.clients</groupId> <artifactId>jedis</artifactId> </dependency> <dependency> <groupId>org.springframework.data</groupId> <artifactId>spring-data-redis</artifactId> </dependency> 集成模式 1）standalone方式集成 spring: redis: host: 127.0

迁移介绍 Redis-port是一款开源的数据批量传输工具，主要用于Redis节点间的数据库同步，该工具具备以下功能： dump 生成缓存快照，将缓存数据导出为rdb文件。 decode 解析rdb文件，查看数据分布情况。 restore 将rdb文件恢复（导入）到实例中。 sync 将Redis实例中的数据同步到另一个Redis实例中。 适宜场景 通过Redis-port导入整库，需要能够获取到RDB文件，适宜以下场景： “数据中心自建Redis服务”迁移到“DCS缓存实例” “华为云自建Redis服务”迁移到“DCS缓存实例” 本文主要介绍基于 Redis-port v2.0-beta版本（linux） 如何从用户自建Redis迁移到华为云DCS中。 步骤1：安装Redis-port 下载和解压工具，可直接使用，无需编译。 在执行导出和导入操作的服务器上都需要安装Redis-port。 wget https://github.com/CodisLabs/redis-port/releases/download/v2.0-beta/redis-port-v2.0-beta-go1.10.1-linux.tar.gz tar -xvf redis-port-v2.0-beta-go1.10.1-linux.tar.gz 步骤2：导出数据 redis-dump -n 3 -m

docker 离线加载 需求: 某某公司网络管控需要，机器只能内网访问。 乙方：需要开发完成后，方便在甲方机器快速部署。 乙方提供镜像，在甲方机器离线部署。 参考 使用redis镜像测试 ➜ ~ docker save redis -o redis.tar ➜ ~ ll -sh redis.tar 230080 -rw------- 1 huoyinghui staff 103M 7 15 16:59 redis.tar ➜ ~ docker rmi redis Untagged: redis:latest Untagged: redis@sha256:800f2587bf3376cb01e6307afe599ddce9439deafbd4fb8562829da96085c9c5 ➜ ~ docker load -i redis.tar Loaded image: redis:latest ➜ ~ ➜ ~ docker run redis 1:C 15 Jul 2020 09:00:34.438 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo 1:C 15 Jul 2020 09:00:34.438 # Redis version=6.0.5, bits=64, commit=00000000, modified=0, pid=1,

undefined Label(标签)是Kubernetes系统中另外一个核心概念。一个Label是 一个key=value的键值对，其中key与value由用户自己指定。Label可以被 附加到各种资源对象上，例如Node、Pod、Service、RC等，一个资源对 象可以定义任意数量的Label，同一个Label也可以被添加到任意数量的 资源对象上。Label通常在资源对象定义时确定，也可以在对象创建后 动态添加或者删除。 我们可以通过给指定的资源对象捆绑一个或多个不同的Label来实 现多维度的资源分组管理功能，以便灵活、方便地进行资源分配、调 度、配置、部署等管理工作。例如，部署不同版本的应用到不同的环境 中;监控和分析应用(日志记录、监控、告警)等。一些常用的Label 示例如下。 ◎ 版本标签:"release":"stable"、"release":"canary"。 ◎ 环境标 签:"environment":"dev"、"environment":"qa"、"environment":"production"。 ◎ 架构标 签:"tier":"frontend"、"tier":"backend"、"tier":"middleware"。 ◎ 分区标签:"partition":"customerA"、"partition":"customerB"。 ◎ 质量管控标签

周六生产服务器出现redis服务器不可用状态，错误信息为: 状态不可用，等待后台检查程序恢复方可使用。Unexpected end of stream; expected type 'Status' 如下图所示，下图6300就是我们redis服务器运行的端口。 头一次碰到此类问题，心想难道是redis挂掉了，随即通过telnet ip+端口。发现运行正常，然后就想着进入redis看下目前连接情况。一看发现竟然高达1903条这么多。 然后想着应该是代码创建redis连接过多导致的，查看代码。 发现redis创建只有这一个地方有，这里也是服务注册时才执行。也就是应用程序启动时才被执行一次。然后整个项目查找，没有其他地方再有调用redis初始化。 心有不甘，难道是每次在redis读写数据时都会创建连接吗？会和读写频繁有关系吗？总感觉不会啊，随即创建测试代码进行测试一番。 在本地搭建了一个redis环境，测试之前先看看接数多少，目前看只有1个，也就是目前的cmd连接客户端，这个属于正常的了。 开始测试，运行程序。代码是创建一个连接对象，并一共测试1000次写，和1000次读。 不管我怎么测试连接都是6个，那么也就是说我们程序最多创建了5个连接，当然主要有线程池在里面。 所以基本的存储读取这块代码肯定是没问题。 但代码这块也没算完全放弃排查

1.请求方使用线程池 多线程请求 2.请求方 使用httpclient 一定要用 http线程池(减少建立tcp连接时的性能消耗) 3.处理方不变的数据放入redis缓存中 4.处理方的查询时的sql优化（整理出慢sql进行优化） 5.处理方集群部署。提高处理效率 来源： oschina 链接： https://my.oschina.net/u/4271231/blog/4293097

存储成本最高降低92% 今天我们正处于数据经济时代，数据量每9个月就会翻一番，用户在享受数据上云的简单与便捷时，存储的TCO成本却在直线上涨。因此，迫切需要成本优化的产品与方案。 阿里云文件存储NAS是一个可共享访问，弹性扩展，高可靠，高性能的分布式文件系统，支持ACL、Quota、文件系统备份等丰富的企业特性，为阿里云上的ECS、ACK、EHPC、BCS、PAI等计算服务提供高性能的共享文件存储。 阿里云文件存储NAS低频型是一款新的存储规格，主要针对不频繁访问的冷数据提供一款低成本大容量的存储类型，通过对数据进行生命周期管理和冷热数据分级存储，达到优化TCO成本的目标。 低频NAS单价¥0.15/月GB，相对价格最高的性能型NAS，成本最高92%。据统计分析，大部分用户80%的数据都是冷数据，按2/8原则进行成本估算，配合低频NAS后，原性能型NAS的有效存储成本可降低至¥0.49/月GB，原容量型NAS的有效存储成本可降低至¥0.19/月GB。 低频NAS工作原理 低频NAS的使用方式非常简单，它和性能型NAS或容量型NAS保持统一的命名空间和一致的访问接口，用户无需修改应用程序，只需要启用生命周期管理，选择低频数据迁移的策略，后台任务会自动根据用户定义的策略将匹配的冷数据迁移到低频NAS。用户无需关心数据迁移任务以及数据实际存储的位置，仍然看到一致的命名空间

本文旨在介绍 vivo 内部的特征存储实践、演进以及未来展望，抛砖引玉，吸引更多优秀的想法。 一、需求分析 AI 技术在 vivo 内部应用越来越广泛，其中特征数据扮演着至关重要的角色，用于离线训练、在线预估等场景，我们需要设计一个系统解决各种特征数据可靠高效存储的问题。 1. 特征数据特点 （1）Value 大 特征数据一般包含非常多的字段，导致最终存到 KV 上的 Value 特别大，哪怕是压缩过的。 （2）存储数据量大、并发高、吞吐大 特征场景要存的数据量很大，内存型的 KV（比如 Redis Cluster）是很难满足需求的，而且非常昂贵。不管离线场景还是在线场景，并发请求量大，Value 又不小，吞吐自然就大了。 （3）读写性能要求高，延时低 大部分特征场景要求读写延时非常低，而且持续平稳，少抖动。 （4）不需要范围查询 大部分场景都是单点随机读写。 （5）定时灌海量数据 很多特征数据刚被算出来的时候，是存在一些面向 OLAP 的存储产品上，而且定期算一次，希望有一个工具能把这些特征数据及时同步到在线 KV 上。 （6）易用 业务在接入这个存储系统时，最好没有太大的理解成本。 2. 潜在需求 扩展为通用磁盘 KV，支撑各个场景的大容量存储需求 我们的目标是星辰大海，绝不仅限于满足特征场景。 支撑其他 Nosql/Newsql 数据库，资源复用 从业务需求出发

常见的IO事件处理模型有两种：Reactor和Proactor。Redis中的ae就是采用的Reactor事件处理模型，Proactor需要操作系统的支持，目前暂时还没接触到相关的使用场景，主要是学习模型结构。 Reactor模型 Handler ：用来标识一个文件描述符 Synchronous Event Demultiplexer ：同步事件多路分解器，由select、poll或者epoll函数来实现，调用后会阻塞，直到等待Handler上的一个或多个事件发生 Event Handler ：事件处理接口 Concrete Event Handler ：事件处理接口的实现类，用来实现应用程序所提供的特定事件处理逻辑 Reactor ：Reactor反应堆，主要实现以下功能： 1）注册和删除关注的文件描述符 2）运行事件循环 3）有就绪事件到来时，分发事件到之前注册的回调函数上处理 Reactor时序图 运行主程序，将关注的事件handler注册到Reactor中 主程序调用Reactor，进入无限事件循环，等待注册的事件到来 当事件到来时，调用select返回待处理的事件，Reactor将事件分发到之前注册的回调函数中去处理 Proactor模型 Handler ：用来标识一个文件描述符； Asynchronous Operation Processor ：异步操作处理器