读写器的产品原理是啥？

Posted 2023-04-24

一套完整的RFID系统，是由阅读器与电子标签（也就是所谓的应答器）及应用软件系统三个部份所组成，其工作原理是Reader发射一特定频率的无线电波能量，用以驱动电路将内部的数据送出，此时Reader便依序接收解读数据，送给应用程序做相应的处理。 以RFID卡片阅读器及电子标签之间的通讯及能量感应方式来看大致上可以分成：感应耦合及后向散射耦合两种。一般低频的RFID大都采用第一种式，而较高频大多采用第二种方式。阅读器根据使用的结构和技术不同可以是读或读/写装置，是RFID系统信息控制和处理中心。阅读器通常由耦合模块、收发模块、控制模块和接口单元组成。阅读器和应答器之间一般采用半双工通信方式进行信息交换，同时阅读器通过耦合给无源应答器提供能量和时序。在实际应用中，可进一步通过Ethernet或WLAN等实现对物体识别信息的采集、处理及远程传送等管理功能。应答器是RFID系统的信息载体，应答器大多是由耦合原件（线圈、微带天线等）和微芯片组成无源单元。RFID射频识别技术，RadioFrequencyIdentification，又称无线射频识别，是一种通信技术，可通过无线电讯号识别特定目标并读写相关数据，而无需识别系统与特定目标之间建立机械或光学接触。射频的话，一般是微波，1-100GHz，适用于短距离识别通信。RFID读写器也分移动式的和固定式的，目前RFID技术应用很广，如：图书馆，门禁系统，食品安全溯源等。

参考技术A

读写器即射频标签读写设备是射频识别系统的两个重要组成部分（标签与读写器）之一。射频标签读写设备根具体实现功能的特点也有一些其他较为流行的别称，如：阅读器（Reader），查询器（Interrogator），通信器（Communicator），扫描器（Scanner），读写器（ReaderandWriter），编程器（Programmer），读出装置（ReadingDevice），便携式读出器（PortableReadoutDevice），AEI设备（AutomaticEquipmentIdentificationDevice）等。通常情况下，射频标签读写设备应根据射频标签的读写要求以及应用需求情况来设计。随着射频识别技术的发展，射频标签读写设备也形成了一些典型的系统实现模式，本章的重点也在于介绍这种读写器的实现原理。从最基本的原理角度出度，射频标签读写设备一般均遵循基本模式。

参考技术B

UHF表示超高频频段，中国超高频频段在（902-928MHz）。其余的还有低频LF高频HF及微波。RFID是无线射频技术，UHFrfid阅读器指的是读取TAG（标签）的阅读设备，通过和标签耦合进行读取。RFID的工作原理是：标签进入磁场后，如果接收到阅读器发出的特殊射频信号，就能凭借感应电流所获得的能量发送出存储在芯片中的产品信息（即PassiveTag，无源标签或被动标签），或者主动发送某一频率的信号（即ActiveTag，有源标签或主动标签），阅读器读取信息并解码后，送至中央信息系统进行有关数据处理。

数据库：读写分离 — 问题汇总

问题：

• 如何实现 MySQL 的读写分离？
• MySQL 主从复制原理是啥？
• 如何解决 MySQL 主从同步的延时问题？

分析

　　高并发这个阶段，肯定是需要做读写分离的，啥意思？因为实际上大部分的互联网公司，一些网站，或者是 app，其实都是读多写少。所以针对这个情况，就是写一个主库，但是主库挂多个从库，然后从多个从库来读，那不就可以支撑更高的读并发压力了吗？

剖析

  如何实现 MySQL 的读写分离？

　　其实很简单，就是基于主从复制架构，简单来说，就搞一个主库，挂多个从库，然后我们就单单只是写主库，然后主库会自动把数据给同步到从库上去。

  MySQL 主从复制原理的是啥？

　　主库将变更写入 binlog 日志，然后从库连接到主库之后，从库有一个 IO 线程，将主库的 binlog 日志拷贝到自己本地，写入一个 relay 中继日志中。接着从库中有一个 SQL 线程会从中继日志读取 binlog，然后执行 binlog 日志中的内容，也就是在自己本地再次执行一遍 SQL，这样就可以保证自己跟主库的数据是一样的。

　　这里有一个非常重要的一点，就是从库同步主库数据的过程是串行化的，也就是说主库上并行的操作，在从库上会串行执行。所以这就是一个非常重要的点了，由于从库从主库拷贝日志以及串行执行 SQL 的特点，在高并发场景下，从库的数据一定会比主库慢一些，是有延时的。所以经常出现，刚写入主库的数据可能是读不到的，要过几十毫秒，甚至几百毫秒才能读取到。

　　而且这里还有另外一个问题，就是如果主库突然宕机，然后恰好数据还没同步到从库，那么有些数据可能在从库上是没有的，有些数据可能就丢失了。

　　所以 MySQL 实际上在这一块有两个机制，一个是半同步复制，用来解决主库数据丢失问题；一个是并行复制，用来解决主从同步延时问题。

　　这个所谓半同步复制，也叫 semi-sync 复制，指的就是主库写入 binlog 日志之后，就会将强制此时立即将数据同步到从库，从库将日志写入自己本地的 relay log 之后，接着会返回一个 ack 给主库，主库接收到至少一个从库的 ack 之后才会认为写操作完成了。

　　所谓并行复制，指的是从库开启多个线程，并行读取 relay log 中不同库的日志，然后并行重放不同库的日志，这是库级别的并行。

MySQL 主从同步延时问题（精华）

　　以前线上确实处理过因为主从同步延时问题而导致的线上的 bug，属于小型的生产事故。

　　是这个么场景。有个同学是这样写代码逻辑的。先插入一条数据，再把它查出来，然后更新这条数据。在生产环境高峰期，写并发达到了 2000/s，这个时候，主从复制延时大概是在小几十毫秒。线上会发现，每天总有那么一些数据，我们期望更新一些重要的数据状态，但在高峰期时候却没更新。用户跟客服反馈，而客服就会反馈给我们。

　我们通过 MySQL 命令：

show status

　查看 Seconds_Behind_Master，可以看到从库复制主库的数据落后了几 ms。

　一般来说，如果主从延迟较为严重，有以下解决方案：

• 分库，将一个主库拆分为多个主库，每个主库的写并发就减少了几倍，此时主从延迟可以忽略不计。
• 打开 MySQL 支持的并行复制，多个库并行复制。如果说某个库的写入并发就是特别高，单库写并发达到了 2000/s，并行复制还是没意义。
• 重写代码，写代码的同学，要慎重，插入数据时立马查询可能查不到。
• 如果确实是存在必须先插入，立马要求就查询到，然后立马就要反过来执行一些操作，对这个查询设置直连主库。不推荐这种方法，你要是这么搞，读写分离的意义就丧失了。

 

出处：https://github.com/doocs/advanced-java/blob/master/docs/high-concurrency/mysql-read-write-separation.md