图片压缩方法、装置、存储介质和电子设备与流程

本申请涉及计算机技术领域，具体而言，涉及一种图片压缩方法、装置、存储介质和电子设备。

背景技术：

很多互联网业务会使用图片，有些图片可能占用比较大的存储空间，直接对这些图片进行处理会消耗大量的资源。因此，需要先对图片进行压缩处理，来解决图片过大的问题。常采用的图片压缩方式为，将接入服务与压缩服务分离，两者之间通过网络通信调用以实现图片压缩功能。

技术实现要素：

为了解决上述问题，本申请实施例提供了一种图片压缩方法、装置、存储介质和电子设备，可以提高请求接入服务和图片压缩服务之间通信的灵活性。本技术方案如下：

第一方面，本申请实施例提供了一种图片压缩方法，包括以下步骤：

获取针对目标图片的图片压缩请求，生成所述图片压缩请求对应的图片压缩任务；

将所述图片压缩任务添加至消息队列中；

从所述消息队列中读取所述图片压缩任务，并执行所述图片压缩任务。

第二方面，本申请实施例提供了一种图片压缩装置，包括：

任务生成单元，用于获取针对目标图片的图片压缩请求，生成所述图片压缩请求对应的图片压缩任务；

任务添加单元，用于将所述图片压缩任务添加至消息队列中；

图片压缩单元，用于从所述消息队列中读取所述图片压缩任务，并执行所述图片压缩任务。

第三方面，本申请实施例提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现上述任一项方法的步骤。

第四方面，本申请实施例提供了一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上述任一项方法的步骤。

在本申请实施例中，通过生成图片压缩请求对应的图片压缩任务，并将图片压缩任务添加至消息队列中。将接入服务和图片压缩服务进行耦合，两者之间可通过消息队列传递图片压缩任务，请求接入服务和图片压缩服务之间无需再通过网络进行通信，两者之间的通信方式更加灵活，图片压缩效率高。

附图说明

图1为本申请实施例提供的一种图片压缩方法的系统架构示意图；

图2为本申请实施例提供的一种图片压缩方法的流程示意图；

图3为本申请实施例提供的另一种图片压缩方法的流程示意图；

图4为本申请实施例提供的另一种图片压缩方法的系统架构示意图；

图5为本申请实施例提供的又一种图片压缩方法的系统架构示意图；

图6为本申请实施例提供的一种图片压缩装置的结构示意图；

图7为本申请实施例所涉及的一种电子设备的结构示意图。

具体实施方式

下面结合附图和实施例对本申请进行进一步的介绍。

在下述介绍中，术语“第一”、“第二”仅为用于描述的目的，而不能理解为指示或暗示相对重要性。下述介绍提供了本申请的多个实施例，不同实施例之间可以替换或者合并组合，因此本申请也可认为包含所记载的相同和/或不同实施例的所有可能组合。因而，如果一个实施例包含特征a、b、c，另一个实施例包含特征b、d，那么本申请也应视为包括含有a、b、c、d的一个或多个所有其他可能的组合的实施例，尽管该实施例可能并未在以下内容中有明确的文字记载。

下面的描述提供了示例，并且不对权利要求书中阐述的范围、适用性或示例进行限制。可以在不脱离本申请内容的范围的情况下，对描述的元素的功能和布置做出改变。各个示例可以适当省略、替代或添加各种过程或组件。例如所描述的方法可以以所描述的顺序不同的顺序来执行，并且可以添加、省略或组合各种步骤。此外，可以将关于一些示例描述的特征组合到其他示例中。

互联网业务常需要对大量的内容数据进行处理。在对内容数据的处理过程中，常会接入很多外部图片数据，这些外部图片有可能是占用空间比较大的图片，如高清大图等。占用空间比较大的图片的处理过程会消耗终端中较多的资源。因此，系统需要先对这类图片进行压缩后，再进行图片处理。

图1为本申请实施例提供的一种图片压缩方法的系统架构示意图。如图1所示，系统将接入服务与图片压缩服务分离，接入服务与压缩服务通过调用的方式进行通信，接入服务将需要压缩的图片链接发送给压缩服务，压缩服务将压缩后的图片链接返回给接入服务，接入服务再将压缩后的图片链接发送给指定的终端。如图1所示的系统架构中，接入服务与压缩服务之间通过网络的方式进行通信，通信方式不够灵活。

基于此，本申请提出了一种图片压缩方法。参见图2，图2为本申请实施例提供的一种图片压缩方法的流程示意图，所述方法包括：

s201、获取针对目标图片的图片压缩请求，生成所述图片压缩请求对应的图片压缩任务。

图片压缩请求可以来自于终端，也可来自于其它服务器。具体地，终端和其它服务器可以通过互联网、无线局域网、蓝牙连接、红外连接等方式，发送图片压缩请求。

可选地，所述图片压缩请求包括目标图片的大小和/或应用类型。系统会基于目标图片的大小和/或应用类型，选择合理的压缩方式，将目标图片压缩至合适大小，以满足后续应用的需要。

s202、将所述图片压缩任务添加至消息队列中。

消息队列是在消息的传输过程中保存消息的容器。消息队列可包括：activemq，rabbitmq，zeromq，kafka等。

s203、从所述消息队列中读取所述图片压缩任务，并执行所述图片压缩任务。

可选地，当所述图片压缩任务包括多个时，步骤s203可包括：

从所述消息队列中读取多个所述图片压缩任务，将各所述图片压缩任务分别分配至线程池中的空闲线程，并控制各所述空闲线程并行执行所述图片压缩任务。

线程池是一种线程使用模式，线程池维护着多个线程，可并发执行多个任务。本申请实施例通过使用线程池，一方面，避免了在短时间内处理多个任务时，创建与销毁线程的代价线程过多会而带来的调度开销，进而使整体性能变慢。另一方面，线程池还能能够保证内核的充分利用，加快系统运行效率。

可选地，所述方法还包括：

获取所述压缩链接的写入失败次数；

若所述写入失败次数超过次数阈值，将所述原始链接添加到黑名单中。

次数阈值可根据具有应用场景来配置。如果压缩连接写入失败的次数过多，可能是目标图片的格式不正常，目标图片文件出现错误等原因。这类目标图片有较大概率无法成功执行压缩的步骤。因此，当压缩连接写入失败的次数超过次数阈值，将所述原始链接添加到黑名单中，以避免该图片压缩任务再次被执行，进而减少系统资源被消耗。

本申请实施例的图片压缩方法，通过生成图片压缩请求对应的图片压缩任务，并将图片压缩任务添加至消息队列中。请求接入服务和图片压缩服务之间可通过消息队列传递图片压缩任务。如图1所示的架构中，接入服务和图片压缩服务之间通过网络通信调用。采用本申请实施例的方法，可使接入服务和图片压缩服务之间的通信方式更加灵活。

此外，本申请的实施例中，可根据具体需要部署接入服务和图片压缩服务，如将接入服务和图片压缩服务都部署在同一台服务器上，也可以对多台服务网进行集群，将接入服务和图片压缩服务部署于集群服务器上。如图1所示的架构中，接入服务器和图片压缩服务分别部署于固定的接入服务器和图片压缩服务器上。相比图1所示的架构，本申请实施例所提供的方法可较灵活地部署业务终端。

此外，如图1所示的架构中，接入服务和图片压缩服务之间采用直接调用的方式进行通信，两者之间的耦合强，且图片压缩服务的压力大。采用本申请实施例的方法，可降低接入服务和图片压缩服务之间的耦合性。另外，本申请实施例的方法中，接入服务和图片压缩服务对消息队列中同一消息进行处理，应用间并发处理消息，相比串行处理，减少了处理时间。

此外，本申请实施例的方法中，接入服务和图片压缩服务通过消息队列对同一消息进行处理，避免由于调用接口失败而导致整个处理过程的失败。

参见图3，图3为本申请实施例提供的一种图片压缩方法的流程示意图，所述方法包括：

s301、获取针对目标图片的图片压缩请求，获取所述目标图片的原始链接。

s302、在缓存中查找是否存在所述原始链接对应的压缩链接。

可通过目标图片的原始链接为键值，在缓存中查找原始链接对应的压缩链接。如果缓存中存储有原始链接对应的压缩链接，则说明该目标图片已被压缩过，直接返回原始链接对应的压缩链接即可。

可选地，s302包括：

在黑名单中查找是否存在所述原始链接；

若在所述黑名单中不存在所述原始链接，则在缓存中查找是否存在所述原始链接对应的压缩链接。

如果黑名单中存在目标图片的原始链接，则说明该目标图片已执行过压缩步骤，且无法成功被压缩。相应于黑名单中存在的目标图片的原始链接，直接向接入服务返回目标图片的原始链接，以避免黑名单中的图片再次被执行压缩的步骤。

s303、若在所述缓存中不存在所述原始链接对应的压缩链接，则返回所述原始链接，并生成所述包含所述原始链接的图片压缩任务。

如果缓存中没有存储原始链接对应的压缩链接，则说明该目标图片没有被压缩过，需要执行下列压缩步骤。

s304、将所述图片压缩任务添加至消息队列中。

s305、从所述消息队列中读取所述图片压缩任务，并执行所述图片压缩任务。

可选地，所述方法还包括：

若在所述缓存中存在所述目标原始链接对应的压缩链接，则返回所述压缩链接。

如果缓存中存储有原始链接对应的压缩链接，则说明该目标图片已被压缩过，直接返回原始链接对应的压缩链接即可。

可选地，s305之后，还包括：

生成所述目标图片对应的压缩链接；

将所述压缩链接写入所述缓存。

将生成的目标图片对应的压缩链接写入缓存。如果后续还需要该目标图片对应的压缩图片，直接在缓存中查找该目标图片对应的压缩链接即可，而无需再重复执行图片压缩的过程。因此，本申请实施例的方法，可节省系统资源，进而提升系统运行速度。

本申请实施例提供的图片压缩方法，先基于缓存查找目标图片对应的压缩链接，在找到的情况下，直接返回压缩链接。在没找到的情况下，再执行后续的图片压缩过程。相比，不通过查找缓存，直接进行图片压缩的方法，可提高系统效率，减少系统不必要的资源消耗。

为使本申请实施例的方法更加便于理解，下面讲解一个具体的实施过程。本实施例提供的技术方案结合分布式技术、缓存技术、消息队列技术等，解耦各个服务依赖，达到服务高并发、低延时、业务通用等图片压缩能力。图4为本申请实施例提供的另一种图片压缩方法的系统架构示意图。如图4所示，整个系统分为2个主体服务：

请求处理服务：该服务用于接收处理图片压缩请求，当请求处理服务接收到请求的时，首先以图片链接为键值(key)，从缓存中查找该图片压缩后的压缩链接。以及以该图片链接为键值，查找该图片是否被拉入黑名单。如果缓存中查找该图片压缩后的压缩链接，则图片已被压缩，返回压缩后的图片连接；如果缓存中未查找该图片压缩后的压缩链接，则该图片未被压缩，返回图片原链，然后将需要压缩的图片链接对应的图片任务放入消息队列。

图片压缩服务：该服务用于对图片进行压缩，从消息队列中读取压缩任务，采用线程池的技术，对多张图片进行同步压缩，并将压缩完成后的图片链接写入缓存，便于后续的请求服务查询。

请求处理服务个图片压缩服务之间通信使用kafka消息队列的方式。通过使用kafka消息队列解耦了两个应用之间的依赖。请求服务通过先在缓存中查询图片的压缩链接的方式，较大的提升了服务的响应的速度。通过kafka消息队列的方式，异步完成了压缩功能，可以在较短时间内完成压缩图片的过程。

图5为本申请实施例提供的又一种图片压缩方法的系统架构示意图。如图5所示，请求处理服务通过https请求获取图片压缩请求。先通过缓存服务查找目标图片是否已被压缩过。如果目标图片已被压缩，则返回压缩图链接；如果没有找到目标图片的压缩图链接，则返回原图片链接，并将目标图片对应的图片压缩任务放入kafka中。

图片压缩服务，通过线程池中的空闲线程从kafka中获取图片压缩任务，并执行图片压缩任务。如果图片压缩任务执行失败的次数较多，则将该图片压缩任务放入黑名单中。如果图片压缩任务执行成功，则将图片上传至缓存中。

本申请实施例的方案，采用请求、压缩服务解耦，功能异步，通过消息队列进行通信等方式，解决压缩服务性能受限的问题。采用压缩服务、请求服务分别部署、缓存等技术，解决高并发请求问题。采用https发送图片压缩请求，实时返回压缩结果，可使图片压缩请求方、请求处理服务方及图片压缩服务方法的业务解耦。因此，本申请实施例的方案具有很强的通用性。

请参见图6，图6是本申请实施例提供的一种图片压缩装置结构示意图。如图6所示，所示图片压缩装置包括：

任务生成单元601，用于获取针对目标图片的图片压缩请求，生成所述图片压缩请求对应的图片压缩任务；

任务添加单元602，用于将所述图片压缩任务添加至消息队列中；

图片压缩单元603，用于从所述消息队列中读取所述图片压缩任务，并执行所述图片压缩任务。

可选地，所述任务生成单元601，具体用于：

获取针对目标图片的图片压缩请求，获取所述目标图片的原始链接；

在缓存中查找是否存在所述原始链接对应的压缩链接；

若在所述缓存中不存在所述原始链接对应的压缩链接，则返回所述原始链接，并生成所述包含所述原始链接的图片压缩任务。

可选地，所述任务生成单元601，还用于：

若在所述缓存中存在所述目标原始链接对应的压缩链接，则返回所述压缩链接。

可选地，所述任务生成单元601，具体用于：

在黑名单中查找是否存在所述原始链接；

若在所述黑名单中不存在所述原始链接，则在缓存中查找是否存在所述原始链接对应的压缩链接。

可选地，所述任务生成单元601，具体用于：

若在所述黑名单中存在所述原始链接，则返回所述原始链接。

可选地，所述装置还包括：

缓存写入单元604，用于生成所述目标图片对应的压缩链接；

将所述压缩链接写入所述缓存。

可选地，当所述图片压缩任务包括多个时，所述图片压缩单元603具体用于：

从所述消息队列中读取多个所述图片压缩任务，将各所述图片压缩任务分别分配至线程池中的空闲线程，并控制各所述空闲线程并行执行所述图片压缩任务。

可选地，所述装置还包括：

黑名单添加单元605，用于获取所述压缩链接的写入失败次数；

若所述写入失败次数超过次数阈值，将所述原始链接添加到黑名单中。

本领域的技术人员可以清楚地了解到本申请实施例的技术方案可借助软件和/或硬件来实现。本说明书中的“单元”和“模块”是指能够独立完成或与其他部件配合完成特定功能的软件和/或硬件，其中硬件例如可以是fpga(field－programmablegatearray，现场可编程门阵列)、ic(integratedcircuit，集成电路)等。

本申请实施例的各处理单元和/或模块，可通过实现本申请实施例所述的功能的模拟电路而实现，也可以通过执行本申请实施例所述的功能的软件而实现。

本申请实施例还提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现上述图片压缩方法的步骤。其中，计算机可读存储介质可以包括但不限于任何类型的盘，包括软盘、光盘、dvd、cd-rom、微型驱动器以及磁光盘、rom、ram、eprom、eeprom、dram、vram、闪速存储器设备、磁卡或光卡、纳米系统(包括分子存储器ic)，或适合于存储指令和/或数据的任何类型的媒介或设备。

参见图6，其示出了本申请实施例所涉及的一种电子设备的结构示意图，该电子设备可以用于实施上述实施例中提供的图片压缩方法。具体来讲：

存储器1020可用于存储软件程序以及模块，处理器1080通过运行存储在存储器1020的软件程序以及模块，从而执行各种功能应用以及数据处理。存储器1020可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序(比如声音播放功能、图像播放功能等)等；存储数据区可存储根据终端设备的使用所创建的数据(比如音频数据、电话本等)等。此外，存储器1020可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。相应地，存储器1020还可以包括存储器控制器，以提供处理器1080和输入单元1030对存储器1020的访问。

输入单元1030可用于接收输入的数字或字符信息，以及产生与用户设置以及功能控制有关的键盘、鼠标、操作杆、光学或者轨迹球信号输入。具体地，输入单元1030可包括触敏表面1031(例如：触摸屏、触摸板或触摸框)。触敏表面1031，也称为触摸显示屏或者触控板，可收集用户在其上或附近的触摸操作(比如用户使用手指、触笔等任何适合的物体或附件在触敏表面1031上或在触敏表面1031附近的操作)，并根据预先设定的程式驱动相应的连接装置。可选的，触敏表面1031可包括触摸检测装置和触摸控制器两个部分。其中，触摸检测装置检测用户的触摸方位，并检测触摸操作带来的信号，将信号传送给触摸控制器；触摸控制器从触摸检测装置上接收触摸信息，并将它转换成触点坐标，再送给处理器1080，并能接收处理器1080发来的命令并加以执行。此外，可以采用电阻式、电容式、红外线以及表面声波等多种类型实现触敏表面1031。

显示单元1040可用于显示由用户输入的信息或提供给用户的信息以及终端设备的各种图形用户接口，这些图形用户接口可以由图形、文本、图标、视频和其任意组合来构成。显示单元1040可包括显示面板1041，可选的，可以采用lcd(liquidcrystaldisplay，液晶显示器)、oled(organiclight-emittingdiode,有机发光二极管)等形式来配置显示面板1041。进一步的，触敏表面1031可覆盖显示面板1041，当触敏表面1031检测到在其上或附近的触摸操作后，传送给处理器1080以确定触摸事件的类型，随后处理器1080根据触摸事件的类型在显示面板1041上提供相应的视觉输出。虽然触敏表面1031与显示面板1041可以是作为两个独立的部件来实现输入和输入功能，但是在某些实施例中，可以将触敏表面1031与显示面板1041集成而实现输入和输出功能。

处理器1080是终端设备的控制中心，利用各种接口和线路连接整个终端设备的各个部分，通过运行或执行存储在存储器1020内的软件程序和/或模块，以及调用存储在存储器1020内的数据，执行终端设备的各种功能和处理数据，从而对终端设备进行整体监控。可选的，处理器1080可包括一个或多个处理核心；其中，处理器1080可集成应用处理器和调制解调处理器，其中，应用处理器主要处理操作系统、用户界面和应用程序等，调制解调处理器主要处理无线通信。可以理解的是，上述调制解调处理器也可以不集成到处理器1080中。

具体在本实施例中，终端设备的显示单元是触摸屏显示器，终端设备还包括有存储器，以及一个或者一个以上的程序，其中一个或者一个以上程序存储于存储器中，且经配置以由一个或者一个以上处理器执行述一个或者一个以上程序包含实现上述图片压缩方法的步骤。

在本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，如：多个单元或组件可以结合，或可以集成到另一个系统，或一些特征可以忽略，或不执行。另外，所显示或讨论的各组成部分相互之间的耦合、或直接耦合、或通信连接可以是通过一些接口，设备或单元的间接耦合或通信连接，可以是电性的、机械的或其它形式的。

在本申请各实施例中的各功能单元可以全部集成在一个处理单元中，也可以是各单元分别单独作为一个单元，也可以两个或两个以上单元集成在一个单元中；上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。

以上介绍仅为本申请的优选实施例而已，并不用于限制本申请，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。