[0001] 本发明属于智慧城市物联网技术领域，具体涉及一种城市路侧停车ETC联网应用的多元异构支付方法。

[0002] 近年来，城市建设日新月异，机动车保有量快速增长。由此带来的城市路内停车收费欠费问题明显，由于道路本身开放性的停车特点，车辆的停放和离场不受外力限制，城市停车逃费成为了影响运营收入流失的问题。

[0003] 目前，大多数城市路侧停车管理收费模式还是以手持POS机+人工收费为主，该模式工作量大、效率低、单人管理区域有限、流程漏洞大，进而导致停车费漏收、欠收现象严重。如今大部分城市停车收费业务引入了传统ETC联网识别收费模式开展停车费助缴功能，但由于项目网络交互、系统延时、车辆行驶速度、ETC绑定账户单一等多方面因素的影响，仍存在车辆识别率低、ETC联网交易失败、用户交易账单产生不及时等问题，导致ETC联网应用技术未能最大化发挥作用，因此需要开发一种能有效解决上述问题，进一步提高联网收费成功率的方法。

[0025] 下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

[0026] 以下结合附图1对本申请作进一步详细说明，本申请实施例公开一种城市路侧停车ETC联网应用的多元异构支付方法，包括如下步骤：
S1、当车辆经过ETC识别扣费设备时，控制器（安装在道路旁边监控立杆上）通过路侧单元RSU（Road‑Side Units）识别车辆车载单元OBU(On board Unit)信息，然后控制器访问SAAS系统平台的应用程序接口API(Application Program Interface)，来查询与该车牌号码相关的订单信息，并通过SAAS系统平台执行数据校验后完成扣费；
其中，路侧单元RSU读取车辆车载单元OBU的信息，包括车辆的车牌号码、车辆类型、ETC卡信息；
SAAS系统是一个云服务平台，提供车辆管理、订单处理、支付处理等服务，SAAS系统接收到查询请求后，会执行数据校验过程，这可能包括验证车牌号码与ETC卡信息的匹配性、检查订单状态（如是否已支付、是否有效等），SAAS系统执行的扣费操作包括从ETC账户中扣除相应的费用，或者在支持多种支付方式的系统中，选择合适的支付渠道进行扣费。

[0027] 同时，为了确保SAAS系统平台在短时间内不会对同一车牌号码的订单进行重复扣费，SAAS系统会对该车牌号码加上一把分布式锁，在分布式系统中，分布式锁是一种机制，用于确保在同一时间内，只有一个进程或线程能够访问特定的资源或执行特定的操作，这里使用redis来实现分布式锁，通过执行SET命令，为特定订单ID（order_id）设置一个分布式锁，这个锁的有效时间设置为60秒，SET命令中的NX参数确保只有当key不存在时才会设置key，这样就避免了重复加锁的问题；在扣费操作完成后，SAAS系统会执行解锁操作，移除之前加上的分布式锁，释放资源，以便其他请求能够访问该车牌号码的订单。

[0028] 采用redis实现分布式锁，通过SET order:lock:{order_id} 1 EX 60 NX命令方式给订单加上分布式锁，此时会在redis存在一条key为order:lock:{order_id}的记录，防止道路上其他控制器继续识别该车辆进行重复识别扣费（道路可能部署多组设备），另外，给步骤S5后续多元异构的支付步骤预留扣费时间；S2、扣费结果上送到SAAS服务端，SAAS将交易订单写入ETC订单表，扣费结果包含失败或者未扣费成功，扣费失败包括余额不足、用户卡是黑名单的情况，未扣费成功情况是指因车速过快，扣费交易步骤并未走完导致流程中断；
在城市路侧停车ETC联网应用中，当车辆经过路侧的ETC识别扣费设备时，控制器会通过路侧单元（RSU）识别车辆的车载单元（OBU）信息。然后，控制器会访问SAAS（软件即服务）系统平台的应用程序接口（API）来查询与该车牌号码相关的订单信息。

[0029] 在查询到订单信息后，控制器会执行数据校验，以确保信息准确无误。如果校验通过，控制器会向RSU发起指令，与车辆的OBU进行通信，从而执行扣费操作。在扣费操作发起时，会生成一份订单记录，并在这个记录中标识扣费的状态（比如成功或失败）。

[0030] 最终，这个扣费结果（包括订单记录和扣费状态）会被上送给SAAS系统。这样，SAAS系统就可以跟踪每辆车的停车费用情况，管理扣费信息，并确保停车费用被正确收取。这个过程是自动化的，无需人工干预，提高了停车收费的成功率和准确性。

[0031] S3、基于订单库binlog日志把每条数据推送到消息队列 Kafka消息队列TopicA；其中，binlog是数据库数据变更日志，每条数据插入修改删除都会产生一条
binlog；TopicA是 kafka的消息主题，worker可以生产或订阅消费；
“每条数据”指的是订单库中记录的每一笔订单的详细信息。这些信息可能包括但不限于订单号（order_num）、支付类型（pay_type）、订单状态、创建时间、更新时间等。当订单在数据库中发生变化时，这些变化会被记录下来，形成一条binlog日志。通过将binlog日志推送到Kafka消息队列的TopicA，系统能够实时的捕捉到订单状态的更新，进而可以触发后续的支付处理流程。这样的设计可以确保支付系统能够快速响应订单的变化，提高交易的实时性和准确性。

[0032] S4、支付worker订阅Kafka的TopicA，并将支付成功的订单状态（这个状态从数据库来源的 binlog数据中记录有每条订单的字段其中包括状态）及时通知至路侧智慧城市停车平台（指第三方城市平台，通常是智慧城市的停车系统），通知其订单支付成功；S5、异构支付worker（异构支付worker是程序中的一个组成单元）订阅Kafka的TopicA，当有新订单，新增时触发以下字段：read_card_type, status；
当有新订单时，会触发read_card_type和status字段的检查：
S5.1、订单因余额不足或者ETC未扣到而扣费失败时，开始执行步骤S6；
S5.2、订单支付为信用卡时(read_card_type==23)，开始执行步骤S6；
S5.3、订单支付为ETC储值卡时(read_card_type==22)，则将订单写入清分表（清分表是记录需要进行清分的ETC订单，最终会把信息上送路网中心进行清分），并进入步骤S8。

[0033] S6、将订单信息先写入delayqueue worker（延迟检查异构无感支付结果）模块，并设置过期时间为50秒，以确保分布式锁到期前(<60秒,即step1设置分布式锁的时间)触发订单支付检查确认逻辑，同时针对该订单发起支付渠道扣款逻辑，按照支付顺序及车辆对应开通情况进行依次尝试扣费，直到其中一个支付渠道支付成功，同时支付记录写入无感支付表（无感支付表存在saas端的数据库中）；delayqueue worker的主要目的是处理那些需要进行异构无感支付检查的订单，并将它们存储起来以便稍后进行检查。

[0034] 当订单被创建时，其信息首先被写入delayqueue worker模块；为了确保订单的支付检查逻辑在分布式锁（设置为60秒）过期之前被触发，订单信息在delayqueue worker中的存储被设置了一个50秒的过期时间。

[0035] 同时，针对每个订单，会按照预先设定的支付顺序和车辆对应的开通情况，依次尝试不同的支付渠道进行扣款。这个过程会持续进行，直到其中一个支付渠道扣款成功。一旦扣款成功，相关的支付记录会被写入无感支付表，这个表存在于SAAS端的数据库中。

[0036] delayqueue worker实现逻辑如下：接收到订单信息后，会对订单ID进行哈希处理，并将Hash值分布到32个逻辑
bucket中，每个bucket存储在Redis数据库的sortset数据结构中，用于存储订单ID，为每个bucket启动一定数量的协程，这些协程会每秒扫描一次，查找到期的订单，一旦找到到期的订单，相关的订单信息会被写入Kafka的TopicB，以便后续的订单确认worker能够处理。

[0037] 总的来说，这一步骤的目的是为了确保订单能够被正确地分配到不同的支付渠道进行尝试扣款，并在分布式锁到期之前触发支付检查逻辑，同时使用delayqueue worker来管理这些订单，确保支付过程的完整性和一致性。

[0038] S7、订单确认worker订阅Kafka的 TopicB进行消费，对到期的订单执行无感支付记录查找确认了，根据不同情况，将订单标记为相应状态，并写入清分表或撤销状态；针对每笔时间到期订单，执行无感支付记录查找确认，逻辑如下：
S7.1、订单ETC支付成功，存在无感扣款也成功，则将ETC订单标记为撤销状态，不再进行清分，进入步骤S8；
S7.2、订单ETC支付成功，不存在无感扣款成功记录，则将ETC订单写入清分表，进入步骤S8；
S7.3、订单ETC支付失败，存在无感扣款成功，进入步骤S9；
S7.4、订单ETC支付失败，也不存在无感扣款成功记录，进入步骤S9。

[0039] S8、将ETC清分表的数据上送至路网进行清分；S9、完成整个支付过程。

[0040] 通过ETC识别和SAAS系统的数据校验，提高了扣费的准确性和成功率，减少了人工操作，防止了漏费和欠费现象。将扣费结果记录在ETC订单表中，确保了交易历史的完整性，便于后续的查询和审计。通过将binlog日志推送到Kafka消息队列，实现了订单状态的实时更新，提高了支付系统的响应速度和交易处理的实时性。及时通知智慧城市停车平台订单支付成功，确保了各相关系统能够及时更新订单状态，提升了整体系统的协同效率。异构支付worker的引入，支持了除了ETC之外的银行无感、数字人民币等其他多种无感支付方式的集成，提供了更丰富的支付选择。delayqueue worker的机制保证了订单支付检查的一致性和幂等性，避免了重复支付或遗漏支付的问题。订单确认worker确保了订单状态处理的一致性和准确性，避免了ETC清分记录的遗漏或过期上送。将ETC清分表的数据上送至路网进行清分，确保了财务记录的准确性，便于后续的财务核对和结算。整个支付过程的完成，标志着系统处理了订单从识别到支付再到确认的全流程，实现了高效、准确的城市路侧停车收费管理。

[0041] 以下介绍用于处理城市路侧停车ETC联网应用中的多元异构支付系统，下面是各个组件和其工作流程的详细说明：关于“支付worker”
幂等及一致性：支付worker使用日志表来确保每笔订单在尝试扣款之前已经成功写入delayqueue worker。如果出现异常，会触发panic，导致进程自动重启（进程发生恐慌崩溃，效果让程序自动进程挂掉，然后由管理进程负责自动重启该进程），以保证订单能够被重新处理。处理记录时，消费kafka时，采用手动commit提交，确保每条记录在处理成功后才commit提交。

[0042] 该支付worker的主要作用有两个：一是处理ETC订单类型，包括储值卡和信用卡的分流逻辑；二是尝试其他支付渠道的无感扣费。

[0043] 扩展性：支持扩展其他无感支付渠道的接入，并可以调整扣款顺序，同时保持对业务端控制器扣款延时的无影响。

[0044] 关于“delayqueue worker”幂等性：delayqueue worker使用Redis的sortset数据结构来存储订单，sortset的特性保证了多次存储的一致性。

[0045] 一致性：当订单设置的时间到期时，会先将订单写入Kafka成功后再删除。如果在写入Kafka时出现异常或写入失败，不会删除订单，而是等待下次协程执行时继续重试。

[0046] 及时性：使用多逻辑Bucket和多协程对应扫描，确保到期订单数据能够及时推送至Kafka消息队列，以便订单确认worker能够及时处理。

[0047] 订单确认worker：作用：订单确认worker确保每笔需要确认的订单能够被及时处理，防止ETC清分记录遗漏或过期上送。

[0048] 一致性：在消费Kafka时采用手动commit，使用本地事务日志表来确保处理逻辑的一致性。如果在执行过程中发生异常，会直接执行panic，然后程序自动重启，接着继续消费，只有在处理成功后才commit。

[0049] 订单分布式锁：作用：在订单支付产生时，对车牌进行一个60秒的分布式锁，以确保车辆在60秒内不会被重复追缴扣费，保证并发扣费时的幂等性。

[0050] delayqueue worker：delayqueue worker保证每笔订单在50秒后被触发，然后由订单确认worker处理至结束流程。

[0051] 总的来说，这是一个高度分化和分布式系统，用于处理多元异构支付，包括ETC和无感支付。系统中使用了分布式锁来确保幂等性和一致性，使用日志表和Kafka来保证事务的持久化和处理的一致性，以及使用了多逻辑Bucket和多协程来提高系统的处理速度和效率。

[0052] 该城市路侧停车ETC联网应用的多元异构支付方法通过引入ETC联网识别和多元异构支付系统，提高了城市路内停车收费的效率和准确性。

[0053] 通过使用ETC识别扣费设备和自动化处理流程，减少了人工介入，从而提高了工作效率。引入分布式锁机制，确保了车辆在一定时间范围内不会被重复扣费，有效减少了逃费和重复扣费的问题。通过使用SAAS系统和Kafka消息队列，实时捕捉订单状态更新，确保了支付系统能够快速响应订单变化，提高了交易的成功率。

[0054] 该方法支持多种支付方式，包括ETC、银行无感，数字人民币等，并通过异构支付worker处理不同支付方式的订单，确保了系统的灵活性和扩展性。通过使用日志表、分布式锁和事务日志，确保了系统在不同环节中的一致性和幂等性，防止了因异常导致的数据不一致问题。订单确认worker的引入，确保了每笔订单在到期后被及时处理，防止了ETC清分记录的遗漏或过期。

[0055] 综上所述，这种多元异构支付方法通过一系列的技术手段，实现了能在一次OBU识别基础上，引入多种无感支付自动扣费支持，且不增加ETC扣费流程的额外延时，有效解决了城市路侧停车收费中存在的技术问题，提高了停车服务的质量和效率。

[0056] 最后应说明的是：以上所述仅为本发明的优选实施例而已，并不用于限制本发明，尽管参照前述实施例对本发明进行了详细的说明，对于本领域的技术人员来说，其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。