Ubuntu远程桌面助手(URDC)最新版

Linux34

自动驾驶DCU及MEC属于典型的Headless设备，常见的方案有Jetson Orin+Ubuntu系统。在开发调试过程需要连接显示器(HDMI/DP)、鼠标和键盘，或使用NoMachine、VNC、ToDesk等远程桌面工具。其中NoMachine功能最强大，兼容性也最好，支持各主流操作系统和ARM嵌入式设备如树莓派等，详细信息请参考《Get started with NoMachine》。VNC是英伟达官方推荐的Jetson远程桌面软件，详细信息请参考《Setup VNC server on the Jetson developer kit》。VNC安装配置运行环境相对复杂，流畅度等使用体验也不如NoMachine。

实际调试过程中，经常需要一台开发主机同时连接多个域控，或一台域控被多个开发主机同时连接。为调试方便，最近将安卓投屏助手(ARDC)移植到Ubuntu下，即Ubuntu远程桌面助手(URDC)，争取将其打造成Ubuntu设备(Jetson/树莓派)开发调试的生产力工具。

Ubuntu远程桌面助手(URDC)使用非常简单，两步即可，具体如下:

1、Windows端安装URDC软件；

2、Windows端运行URDC.exe，并在菜单设备—设置设备的IP、SSH端口、用户名和密码，即可自动连接;

Ubuntu远程桌面助手(URDC)主要功能：

1、通过Windows连接至Ubuntu设备(x86和ARM架构)，实时显示Ubuntu/CentOS桌面;

2、支持通过Windows的鼠标、键盘和输入法远程操控Ubuntu设备;

3、支持双向同步剪切板，可在Windows和Ubuntu设备之间拷贝文本;

4、同一Ubuntu设备最多可同时被三台Windows客户端连接和操控;

5、支持常用调试命令的快速输入，双击CMD列表即可在Ubuntu终端内运行;

6、支持增加自定义的调试命令，可通过文本进行编辑;

7、基于pscp和plink实现文件拖拽上传，一键下载等功能;

8、集成了常用的MobaXterm、putty、WinSCP等Linux调试软件;

Original: https://www.cnblogs.com/we-hjb/p/16390753.html
Author: sunrain_hjb
Title: Ubuntu远程桌面助手(URDC)最新版

相关阅读1

Title: Redis集群搭建准备，了解一致性哈希算法和哈希槽

一致性哈希是在哈希取余算法基础之上优化的，分布式缓存数据变动和映射问题，某个机器宕机了，分母数量改变了，自然取余数不对了。用于解决分布式缓存系统中的数据选择节点存储问题和数据选择节点读取问题以及在增删节点后减少数据缓存的消失范畴，防止雪崩的发生。

哈希槽是在redis cluster集群方案中采用的，redis cluster集群没有采用一致性哈希方案，而是采用数据分片中的哈希槽来进行数据存储与读取的。

一致性哈希
一致性hash是指将 "存储节点" 和 "数据" 都映射到一个首尾相连的hash环上。如果增删节点，仅影响该节点在hash环上顺时针相邻的后继节点，其他数据不会受到影响。

三步：

1：算法构建一致性哈希环。

对存储节点进行哈希计算，也就是对存储节点做哈希映射，比如根据节点的 IP 地址进行哈希（用ip地址对环上的节点个数进行hash，比如ip地址为1.2.3.4，节点个数N，那么可映射到第1234%N的位置上）

2：服务器IP节点映射。

当对数据进行存储或访问时，对数据进行哈希映射； 将存储的key进行hash(key),然后将其值要分布在这个闭合圆上。

一致性Hash算法使用 "取模法"，且是对 2^32 次方取模，其可表示的范围为：0 ~ 2^32-1。

3：key落到服务器的落键规则。

将数据key使用Hash函数计算出哈希值，并确定此数据在环上的位置，从此位置沿环顺时针"行走"，第一台遇到的服务器就是其应该定位到的服务器！
比如：a、b、c三个key，经过哈希计算后，在环空间上的位置如下：key-a存储在node1，key-b存储在node2，key-c存储在node3。

与普通的hash算法有何不同？
普通的hash算法是对节点数进行hash，而一致性hash是对固定值2^32进行取模。

优点：

将数据key使用Hash函数计算出哈希值，并确定此数据在环上的位置，从此位置沿环顺时针"行走"，第一台遇到的服务器就是其应该定位到的服务器！
比如：a、b、c三个key，经过哈希计算后，在环空间上的位置如下：key-a存储在node1，key-b存储在node2，key-c存储在node3。一致性Hash算法对于节点的增减都只需重定位环空间中的一小部分数据，具有较好的容错性和可扩展性。
新增服务器节点/删除服务器节点：
在hash环中新增服务器，也是通过hash算法确认分布，只需要移动一小部分数据即可；移除也是同理（比如下图中想删除4节点，只需把原本1~4节点之间的数据移动到2节点上即可）。

Ubuntu远程桌面助手(URDC)最新版

缺点：（数据倾斜）

但是一致性哈希算法不能够均匀的分布节点，会出现大量请求都集中在一个节点的情况，在这种情况下进行容灾与扩容时，容易出现雪崩的连锁反应。
当在服务器节点数量太少的时候，容易出现分布不均而导致数据倾斜。
例如：系统中只有两台服务器，此时必然造成大量数据集中到Node 2上，而只有极少量会定位到Node 1上。所以用一致性哈希算法时，节点太少容易出现数据倾斜，就达不到了分布式效果。其环分布如下

Ubuntu远程桌面助手(URDC)最新版

总结：一致性Hash算法，主要是考虑到分布式系统每个节点都有可能失效，并且新的节点很可能动态的增加进来的情况。如何保证当系统的节点数目发生变化的时候（新增/删减），我们的系统仍然能够对外提供良好的服务(不用停掉所有redis服务)，这是值得考虑的！

哈希槽

哈希槽解决了数据均匀分布的问题，在数据和节点之间又加入了一层，把这层称之为哈希槽，用于管理数据和节点之间的关系，现在就相当于节点上放的是槽，槽里放数据。

Ubuntu远程桌面助手(URDC)最新版

槽解决的是粒度问题，相当于把粒度变大了，这样便于数据移动。

原理

  • 只是进行不重复的基数统计，不是集合也不保存数据，只记录数量而不是具体内容。
  • 有误差，非精准统计，牺牲准确率来换取空间，误差仅仅只是0.81%左右。误差来自Redis之父回答。

redis cluster采用数据分片的哈希槽来进行数据存储和数据的读取。redis cluster一共有2^14（16384）个槽，所有的master节点都会有一个槽区比如0～1000，槽数是可以迁移的。master节点的slave节点不分配槽，只拥有读权限。但是注意在代码中redis cluster执行读写操作的都是master节点，并不是读是从节点，写是主节点。

为什么是16384个槽？

hash方式：
一个redis集群包含 16384 个哈希槽，编号0-16383（0-2*14-1）。这些槽会分配给集群中的所有主节点，分配策略没有要求，可以指定哪些编号的槽分配给哪个主节点。集群会记录节点槽的对应关系，解决了节点和槽的关系后，接下来就需要对key求哈希值，然后对16384取余，余数是及，那么Key就落入对应的槽里。集群使用公式 CRC16(key) % 16384 来计算键 key 属于哪个槽。
一个redis节点包含N个槽，数据通过hash算法哈希到固定的槽里，所以槽只是决定了数据的存放位置，当多个数据hash出来的结果相同时，他们就被分配到相同的槽里，即也会映射到相同的服务节点上。

在握手成功后，两个节点之间会定期发送ping/pong消息，交换数据信息，在redis节点发送心跳包时需要把所有的槽信息放到这个心跳包里，以便让节点知道当前集群信息，在发送心跳包时使用char进行bitmap压缩后是2k（16384÷8÷1024=2kb），也就是说使用2k的空间创建了16k的槽数。
虽然使用CRC16算法最多可以分配65535（2^16-1）个槽位，65535=65k，压缩后就是8k（8 * 8 (8 bit) * 1024(1k) = 8K），也就是说需要需要8k的心跳包，作者认为这样做不太值得；并且一般情况下一个redis集群不会有超过1000个master节点，所以16k的槽位是个比较合适的选择。

Ubuntu远程桌面助手(URDC)最新版

再来一个图

Ubuntu远程桌面助手(URDC)最新版

①如果槽位为65536，发送心跳信息的消息头达8k，发送的心跳包过于庞大。
②redis的集群主节点数量基本不可能超过1000个。集群节点越多，心跳包的消息体内携带的数据越多。如果节点过1000个，也会导致网络拥堵。因此redis作者，不建议redis cluster节点数量超过1000个。
③槽位越小，节点少的情况下，压缩率高
Redis主节点的配置信息中，它所负责的哈希槽是通过一张bitmap的形式来保存的，在传输过程中，会对bitmap进行压缩，但是如果bitmap的填充率slots / N很高的话(N表示节点数)，bitmap的压缩率就很低。
如果节点数很少，而哈希槽数量很多的话，bitmap的压缩率就很低。

哈希槽和一致性哈希相比
并不是闭合的，key的定位规则是根据CRC-16(key)%16384的值来判断属于哪个槽区，从而判断该key属于哪个节点，而一致性哈希是根据hash(key)的值来顺时针找第一个hash(ip)的节点，从而确定key存储在哪个节点。
一致性哈希是创建虚拟节点来实现节点宕机后的数据转移并保证数据的安全性和集群的可用性的。redis cluster是采用master节点有多个slave节点机制来保证数据的完整性的,master节点写入数据，slave节点同步数据。当master节点挂机后，slave节点会通过选举机制选举出一个节点变成master节点，实现高可用。但是这里有一点需要考虑，如果master节点存在热点缓存，某一个时刻某个key的访问急剧增高，这时该mater节点可能操劳过度而死，随后从节点选举为主节点后，同样宕机，进入fail状态。
扩容和缩容
一致性哈希算法在新增和删除节点后，数据会按照顺时针来重新分布节点。而redis cluster的新增和删除节点都需要手动来分配槽区。

为什么redis集群不采用一致性哈希算法？
一致性哈希的节点分布基于圆环，无法很好的手动控制数据分布，比如有些节点的硬件差，希望少存一点数据，这种很难操作（还得通过虚拟节点映射，总之较繁琐）。
而redis集群的槽位空间是可以用户手动自定义分配的，类似于 windows 盘分区的概念，可以手动控制大小。
其实，无论是一致性哈希还是哈希槽的方式，在增减节点的时候，都会对一部分数据产生影响，都需要我们迁移数据，当然，redis集群也提供了相关手动迁移槽数据的命令。

Original: https://www.cnblogs.com/wt645631686/p/16398332.html
Author: 温柔的风
Title: Redis集群搭建准备，了解一致性哈希算法和哈希槽

相关阅读2

Title: 4.2 Linux tar打包命令详解

Linux 系统中，最常用的归档（打包）命令就是 tar，该命令可以将许多文件一起保存到一个单独的磁带或磁盘中进行归档。不仅如此，该命令还可以从归档文件中还原所需文件，也就是打包的反过程，称为解打包。

使用 tar 命令归档的包通常称为 tar 包（tar 包文件都是以".tar"结尾的）。

tar命令做打包操作

当 tar 命令用于打包操作时，该命令的基本格式为：

[root@localhost ~]#tar [选项] 源文件或目录

此命令常用的选项及各自的含义如表 1 所示。

选项 含义 -c 将多个文件或目录进行打包。 -A 追加 tar 文件到归档文件。 -f 包名 指定包的文件名。包的扩展名是用来给管理员识别格式的，所以一定要正确指定扩展名； -v 显示打包文件过程；

需要注意的是，在使用 tar 命令指定选项时可以不在选项前面输入"-"。例如，使用"cvf"选项和 "-cvf"起到的作用一样。

下面给大家举几个例子，一起看看如何使用 tar 命令打包文件和目录。

【例 1】打包文件和目录。

[root@localhost ~]# tar -cvf anaconda-ks.cfg.tar anaconda-ks.cfg
\#把anacondehks.cfg打包为 anacondehks.cfg.tar文件

选项 "-cvf" 一般是习惯用法，记住打包时需要指定打包之后的文件名，而且要用 ".tar" 作为扩展名。打包目录也是如此：

[root@localhost ~]# ll -d test/
drwxr-xr-x 2 root root 4096 6月 17 21:09 test/
\#test是我们之前的测试目录
[root@localhost ~]# tar -cvf test.tar test/
test/
test/test3
test/test2
test/test1
\#把目录打包为test.tar文件
tar命令也可以打包多个文件或目录，只要用空格分开即可。例如:
[root@localhost ~]# tar -cvf ana.tar anaconda-ks.cfg /tmp/
\#把anaconda-ks.cfg文件和/tmp目录打包成ana.tar文件包

【例 2】打包并压缩目录。
首先声明一点，压缩命令不能直接压缩目录，必须先用 tar 命令将目录打包，然后才能用 gzip 命令或 bzip2 命令对打包文件进行压缩。例如：

[root@localhost ~]#ll -d test test.tar
drwxr-xr-x 2 root root 4096 6月 17 21:09 test
-rw-r--r-- 1 root root 10240 6月 18 01:06 test.tar
\#我们之前已经把test目录打包成test.tar文件
[root@localhost ~]# gzip test.tar
[root@localhost ~]# ll test.tar.gz
-rw-r--r-- 1 root root 176 6月 18 01:06 test.tar.gz
\#gzip命令会把test.tar压缩成test.tar.gz

tar命令做解打包操作

当 tar 命令用于对 tar 包做解打包操作时，该命令的基本格式如下：

[root@localhost ~]#tar [选项] 压缩包

当用于解打包时，常用的选项与含义如表 2 所示。

选项 含义 -x 对 tar 包做解打包操作。 -f 指定要解压的 tar 包的包名。 -t 只查看 tar 包中有哪些文件或目录，不对 tar 包做解打包操作。 -C 目录 指定解打包位置。 -v 显示解打包的具体过程。

其实解打包和打包相比，只是把打包选项 "-cvf" 更换为 "-xvf"。我们来试试：

[root@localhost ~]# tar -xvf anaconda-ks.cfg. tar
\#解打包到当前目录下

如果使用 "-xvf" 选项，则会把包中的文件解压到当前目录下。如果想要指定解压位置，则需要使用 "-C(大写)" 选项。例如：

[root@localhost ~]# tar -xvf test.tar -C /tmp
\#把文件包test.tar解打包到/tmp/目录下

如果只想查看文件包中有哪些文件，则可以把解打包选项 "-x" 更换为测试选项 "-t"。例如：

[root@localhost ~]# tar -tvf test.tar
drwxr-xr-x root/root 0 2016-06-17 21:09 test/
-rw-r-r- root/root 0 2016-06-17 17:51 test/test3
-rw-r-r- root/root 0 2016-06-17 17:51 test/test2
-rw-r-r- root/root 0 2016-06-17 17:51 test/test1
\#会用长格式显示test.tar文件包中文件的详细信息

tar命令做打包压缩（解压缩解打包）操作

你可能会觉得 Linux 实在太不智能了，一个打包压缩，居然还要先打包成 ".tar" 格式，再压缩成 ".tar.gz" 或 ".tar.bz2" 格式。其实 tar 命令是可以同时打包压缩的，前面的讲解之所打包和压缩分开，是为了让大家了解在 Linux 中打包和压缩的不同。

当 tar 命令同时做打包压缩的操作时，其基本格式如下：

[root@localhost ~]#tar [选项] 压缩包 源文件或目录

此处常用的选项有以下 2 个，分别是：

  • -z：压缩和解压缩 ".tar.gz" 格式；
  • -j：压缩和解压缩 ".tar.bz2"格式。

【例 1】压缩与解压缩 ".tar.gz"格式。

[root@localhost ~]# tar -zcvf tmp.tar.gz /tmp/
\#把/temp/目录直接打包压缩为".tar.gz"格式，通过"-z"来识别格式，"-cvf"和打包选项一致

解压缩也只是在解打包选项 "-xvf" 前面加了一个 "-z" 选项。

[root@localhost ~]# tar -zxvf tmp.tar.gz
\#解压缩与解打包".tar.gz"格式

前面讲的选项 "-C" 用于指定解压位置、"-t" 用于查看压缩包内容，在这里同样适用。

【例 2】压缩与解压缩 ".tar.bz2" 格式。
和".tar.gz"格式唯一的不同就是"-zcvf"选项换成了 "-jcvf"，如下所示：

[root@localhost ~]# tar -jcvf tmp.tar.bz2 /tmp/
\#打包压缩为".tar.bz2"格式，注意压缩包文件名
[root@localhost ~]# tar -jxvf tmp.tar.bz2
\#解压缩与解打包".tar.bz2"格式

把文件直接压缩成".tar.gz"和".tar.bz2"格式，才是 Linux 中最常用的压缩方式，这是大家一定要掌握的压缩和解压缩方法。

tar 命令最初被用来在磁带上创建备份，现在可以在任何设备上创建备份。利用 tar 命令可以把一大堆的文件和目录打包成一个文件，这对于备份文件或是将几个文件组合成为一个文件进行网络传输是非常有用的。

Original: https://www.cnblogs.com/qinlulu/p/16230230.html
Author: 开源Linux
Title: 4.2 Linux tar打包命令详解

相关阅读3

Title: prometheus监控redis集群

【1】利用 redis_exporter 监控 redis 集群

（1.0）redis_exporter

以前都是用傻办法，一个实例一个采集器；

redis_exporter 支持的参数很多，对我们有用的就几个。

./redis_exporter --help
Usage of ./redis_exporter:
    -redis.addr string
        Address of the Redis instance to scrape (default "redis://localhost:6379")
    -redis.password string
        Password of the Redis instance to scrape
    -web.listen-address string
        Address to listen on for web interface and telemetry. (default ":9121")

本来想采取最low 的方法，一个实例启一个 redis_exporter。这样子的话，集群那里很多语句都用不了，比如 cluster_slot_fail。放弃该方法

nohup ./redis_exporter -redis.addr 172.18.11.139:7000  -redis.password xxxxxx  -web.listen-address 172.18.11.139:9121 > /dev/null 2>&1 &
nohup ./redis_exporter -redis.addr 172.18.11.139:7001  -redis.password xxxxxx  -web.listen-address 172.18.11.139:9122 > /dev/null 2>&1 &
nohup ./redis_exporter -redis.addr 172.18.11.140:7002  -redis.password xxxxxx  -web.listen-address 172.18.11.139:9123 > /dev/null 2>&1 &
nohup ./redis_exporter -redis.addr 172.18.11.140:7003  -redis.password xxxxxx  -web.listen-address 172.18.11.139:9124 > /dev/null 2>&1 &
nohup ./redis_exporter -redis.addr 172.18.11.141:7004  -redis.password xxxxxx  -web.listen-address 172.18.11.139:9125 > /dev/null 2>&1 &
nohup ./redis_exporter -redis.addr 172.18.11.141:7005  -redis.password xxxxxx  -web.listen-address 172.18.11.139:9126 > /dev/null 2>&1 &

（1.1）redis集群情况

redis集群IP和端口，集群配置了密码

136.xxx.102.112:7000
136.xxx.102.112:7001
136.xxx.102.112:7002
136.xxx.102.113:7000
136.xxx.102.113:7001
136.xxx.102.113:7002

（1.2）redis_exporter部署，配置prometheus

将文件解压并修改文件夹名称，插件不一定安装redis端

tar -zxvf redis_exporter-v1.3.5.linux-amd64.tar.gz
mv redis_exporter-v1.3.5.linux-amd64 redis_exporter

修改prometheus配置，注意文件格式，如果文件有问题会导致prometheus无法启动

vi prometheus.yml

#将文件解压并修改文件夹名称，插件不一定安装redis端
tar -zxvf redis_exporter-v1.3.5.linux-amd64.tar.gz
mv redis_exporter-v1.3.5.linux-amd64 redis_exporter
#修改prometheus配置，注意文件格式，如果文件有问题会导致prometheus无法启动
vi prometheus.yml
  - job_name: 'redis_exporter_targets'
    static_configs:
      - targets:
        - redis://136.127.102.112:7000
        - redis://136.127.102.112:7001
        - redis://136.127.102.112:7002
        - redis://136.127.102.113:7000
        - redis://136.127.102.113:7001
        - redis://136.127.102.113:7002
    params:
      check-keys: ["metrics:*"]
    metrics_path: /scrape
    relabel_configs:
      - source_labels: [__address__]
        target_label: __param_target
      - source_labels: [__param_target]
        target_label: instance
      - target_label: __address__
        replacement: 136.127.102.112:9122
  - job_name: 'redis_exporter'
    static_configs:
      - targets:
        - 136.127.102.112:9122

相关参考：

其实官方文档已经写了。

scrape_configs:
  ## config for the multiple Redis targets that the exporter will scrape
  - job_name: 'redis_exporter_targets'
    static_configs:
      - targets:
        - redis://first-redis-host:6379
        - redis://second-redis-host:6379
        - redis://second-redis-host:6380
        - redis://second-redis-host:6381
    metrics_path: /scrape
    relabel_configs:
      - source_labels: [__address__]
        target_label: __param_target
      - source_labels: [__param_target]
        target_label: instance
      - target_label: __address__
        replacement: <>:9121

  ## config for scraping the exporter itself
  - job_name: 'redis_exporter'
    static_configs:
      - targets:
        - <>:9121

（1.3）采集器（探针）启动

#启动探针，因为是集群只需要写清楚密码即可，默认监听端口为9121，由于有密码需要将端口设置为9122
nohup ./redis_exporter -redis.password passwd123 -web.listen-address 0.0.0.0:9122 &
#prometheus需要重启 或者 reload 重载

（1.4）效果

Ubuntu远程桌面助手(URDC)最新版

【参考文档】

转自：https://blog.csdn.net/weixin_43135696/article/details/122258105

Original: https://www.cnblogs.com/gered/p/16497441.html
Author: 郭大侠1
Title: prometheus监控redis集群