1. Antecedentes

Jinli Platform, como plataforma de comercio electrónico B2B2C a nivel empresarial, atiende tanto a clientes corporativos como a empleados corporativos, por lo que debe seguir las políticas y regulaciones de los clientes corporativos para garantizar que los productos en el centro comercial cumplan con las regulaciones y mejorar el empleado. Experiencia en compras. Sin embargo, este modelo operativo único ha llevado a un problema más prominente de productos visibles e invendibles en la plataforma Jinli, lo que ha tenido un mayor impacto negativo en la experiencia de compra del consumidor final y en los productos y negocios de la plataforma.

2. Solución

Como dice el título, la razón por la que se llama un pequeño truco es porque no utilizamos ninguna tecnología de alta precisión, sino que simplemente combinamos una variedad de tecnologías maduras y agregamos algunos algoritmos.

Las siguientes son las 3 versiones de las iteraciones de la solución que hemos experimentado, que también representan la transformación de una persona técnica del pensamiento técnico al pensamiento empresarial.

Versión 1.0 : intentamos agregar una máscara a los artículos que no se pueden vender para marcar el motivo por el cual no se pueden vender para evitar que los clientes realicen un mal funcionamiento. Sin embargo, este enfoque no resuelve completamente el problema, ya que los consumidores aún pueden estar confundidos sobre por qué ciertos artículos no están disponibles para la venta (por ejemplo, por qué no se puede comprar oro en la plataforma Jinli o por qué los artículos que ven están en la lista negra).

Versión 2.0 : Nos esforzamos por mejorar la eficiencia de la búsqueda, acelerar la entrega de productos invendibles desde el almacén y optimizar el mecanismo de sincronización de productos para reducir la frecuencia de productos invendibles. Sin embargo, con la expansión de las reglas de invendibilidad de la plataforma Jinli (como reglas de precios y restricciones de inversión de precios, etc.), este enfoque personalizado era demasiado complejo para el equipo de búsqueda.

Versión 3.0 : A medida que profundizamos nuestra comprensión de las necesidades de los consumidores, gradualmente nos damos cuenta de que, aunque nuestros primeros métodos han reducido la cantidad de productos invendibles, incluso si solo hay un producto invendible en la plataforma, puede tener un impacto en la experiencia de compra del consumidor. .causar pérdidas. Por lo tanto, necesitamos utilizar medios técnicos para "ocultar" estos productos.

Descripción general del plan

Figura 1 Herramienta de filtrado secundaria

Vista previa del plan

Cuando llegamos a 3.0, primero dedujimos las siguientes dos opciones:

Precarga del front-end : cada vez que el front-end realiza una solicitud, solicitará datos del back-end de acuerdo con la cantidad de visualizaciones por página y, después de recibir los resultados devueltos por el back-end, los datos se filtrarán. según las reglas establecidas. Si la cantidad de datos filtrados es insuficiente, se seguirá solicitando la siguiente página de datos desde el backend.
Sondeo de backend : el backend enviará continuamente solicitudes a la interfaz descendente y cada solicitud incrementará el número de página hasta que se obtengan los resultados de datos que cumplan con las condiciones.

Sin embargo, las deficiencias de las soluciones técnicas anteriores también son obvias:

Las solicitudes iniciadas por el front-end y filtradas darán como resultado una lógica empresarial de front-end redundante, que es inconsistente con el posicionamiento de la capa de vista de front-end.
Si la solicitud iniciada por el front-end no recibe datos, intentará realizar la solicitud nuevamente. Si varias solicitudes tienen problemas de datos incompletos, esto puede causar que el flujo en cascada del front-end se congele, lo que se manifiesta como velocidades de carga que a veces son rápidas y otras lentas, dando a los consumidores la ilusión de que la red se congela.
El front-end con frecuencia inicia solicitudes no válidas, lo que provocará un consumo innecesario de tráfico de red.
Las solicitudes de backend siempre carecen de estado y, si no se manejan correctamente, pueden provocar fácilmente la adquisición repetida de datos o confusión en los números de página.
La profundidad del sondeo de solicitudes de backend no se puede configurar dinámicamente. Si se configura incorrectamente, es fácil que la interfaz se agote.

Hemos realizado una serie de optimizaciones para abordar la posibilidad de que la precarga de front-end pueda complicar la lógica empresarial de front-end y la introducción del sondeo de back-end pueda causar problemas de sincronización de datos.

Introdujimos dos componentes importantes, registros y filtros, para programar y procesar de manera razonable las solicitudes originales.

En primer lugar, el registro se utiliza para almacenar temporalmente datos del producto, de modo que el front-end solo necesita enviar una solicitud desde el front-end al registro cada vez para obtener los datos más recientes del producto, evitando solicitudes repetidas y problemas de tiempo de espera con el back-end. finalizar la votación.

En segundo lugar, los filtros se utilizan para filtrar y procesar datos de productos. Después de obtener los datos del producto más recientes, el filtro filtrará los datos de acuerdo con ciertas reglas, seleccionará los datos del producto que cumplan con las especificaciones de la política y las necesidades del usuario, y se los mostrará al usuario. Al mismo tiempo, para los datos de productos que no cumplen con las especificaciones de la política o contienen productos ilegales, el filtro los oculta o los marca como no vendibles para evitar que los usuarios compren productos ilegales por error.

A través de dicha optimización, no solo evitamos el problema de complicar la lógica empresarial de front-end, sino que también solucionamos los problemas de sincronización de datos que pueden surgir en el sondeo de back-end. Al mismo tiempo, la interfaz modificada sigue siendo una interfaz REST normal, que puede ser fácilmente entendida y utilizada tanto por el front-end como por el back-end.

Figura 2 Composición de las herramientas de filtrado.

La siguiente es una introducción a las funciones de cada enlace.

solicitud original (solicitud de origen)

Hay tres solicitudes de lista comunes:

1. Servicios de consulta proporcionados por terceros, solicitudes de paginación RPC, como la interfaz RPC de la lista de productos de búsqueda, la interfaz RPC de la lista de productos recomendados

2. Consulta de base de datos, consulta de paginación mybatis, puede utilizar la identificación de clave primaria incrementada automáticamente para realizar solicitudes posteriores

3. Consulta de búsqueda ES, consulta de paginación ES, consulta de desplazamiento

Parámetros de entrada: PageParams<T>, parámetros de solicitud de paginación estándar, T es el objeto de solicitud de paginación real

Parámetros de salida: PageResult < R > , parámetros de retorno de paginación estándar, R es el objeto de retorno de solicitud de paginación real

La implementación del SDK se basa en un desarrollo genérico y la persona que llama debe personalizar el método de acuerdo con las especificaciones.

filtro (filtro de cliente)

Parámetros de entrada: Lista < R > sourceData, lista de resultados de devolución original

Parámetros de salida: Lista < R > targetData, filtrar la lista de resultados filtrados

La implementación del SDK se basa en un desarrollo genérico y la persona que llama debe personalizar el método de acuerdo con las especificaciones.

registro (registro de almacenamiento)

Implementados a través de middleware de almacenamiento en caché, los resultados de las consultas se almacenan temporalmente y se obtienen del registro primero después de que llega la solicitud de front-end. Los parámetros de la solicitud se comprimen mediante el algoritmo para garantizar que los mismos parámetros de la solicitud puedan obtener el mismo valor para determinar si se trata de una solicitud con la misma condición de consulta.

La estructura clave del registro es la siguiente:

scroll_id: algoritmo de compresión MD5 del parámetro de entrada pin&activiivtyCode&uid&query,

Además, los parámetros de entrada de la consulta deben excluir los números de página y los parámetros que cambian dinámicamente.

Contenido de almacenamiento: el caché completa la instantánea de los datos restantes después de la paginación, el número de página de solicitud de front-end y el número de página de solicitud de back-end real

coordinador ( coordinar )

El coordinador implementa la complementación de datos, consulta, depósito y retiro de instantáneas de datos de registro y actualizaciones de datos relacionados con la paginación.

1. El coordinador amplía el tamaño del paso en función de la solicitud de front-end original y la solicitud de back-end real para extraer datos posteriores.

2. El front-end y el back-end realizan solicitudes en pasos fijos. Por ejemplo, el front-end solicita 10 elementos cada vez y el back-end solicita 20 elementos cada vez. La proporción del tamaño del paso se puede ajustar dinámicamente de acuerdo con la situación real.

3. La profundidad de la solicitud y la relación del tamaño del paso frontal y posterior se controlan a través de ducc. Por ejemplo: el front-end solicita 10 datos por página y la proporción de pasos es 3, luego el back-end solicita 30 datos por página cada vez; la profundidad de la solicitud es 2, y si la solicitud se realiza dos veces, se verá obligado a detenerse si aún no cumple con los requisitos. Parámetros de solicitud de personalización de dimensiones del cliente

{
 "DEFAULT": {
 "deep": 2,
 "multiple": 3
 },
 "营销测试2": {
 "deep": 2,
 "multiple": 5
 },
 "呼铁福利商城采购账号": {
 "deep": 2,
 "multiple": 4
 }
}

Principio del sistema

Figura 3 Diagrama de flujo de filtrado secundario de datos

Dividimos el filtrado secundario de datos en las siguientes cuatro etapas:

Etapa de consulta:

Reciba la solicitud de front-end y determine la solicitud de interfaz de back-end en función del tamaño de los datos en el registro. El back-end realiza solicitudes RPC de acuerdo con el front-end N veces el tamaño del paso. El resultado del hit creará un instantánea de la cola de prioridad en el caché y pase la clave de caché scroll_id (dimensión C)) apunta a ella, lastPageNo apunta al número de la última página visitada y realPageNo apunta al número de página visitada real.

Etapa de filtrado:

Lea las reglas de filtrado e implemente el filtrado de datos. Las reglas de filtrado de uso común, como: no a la venta, agotado, precio superior al precio de mercado, etc., los datos que no cumplen con las reglas se eliminan directamente.

Etapa de caché:

• Si los datos filtrados son más pequeños que el tamaño del paso de la solicitud de front-end, continúe ingresando a la etapa de Consulta para complementar los datos instantáneos de la cola de prioridad.

• Si los datos filtrados son mayores o iguales que el tamaño del paso de la solicitud de front-end, la lista de datos de pageSize se devolverá directamente y los datos restantes se colocarán en la instantánea de la cola de prioridad.

• La profundidad de la solicitud de back-end se establece temporalmente en 2 veces. Si los datos filtrados aún no cumplen con el paso de la solicitud de front-end después de dos solicitudes de back-end, la solicitud no continuará.

• Si la solicitud de back-end no regresa varias veces, el disyuntor se romperá a tiempo y se devolverán los datos restantes en el registro, y la identificación del resultado devuelto no es la última página.

etapa de búsqueda

A través de las dos etapas anteriores, podemos obtener un conjunto de datos que cumpla con el tamaño del paso de la solicitud de front-end, complementar otra información auxiliar y devolver la estructura de datos de paginación.

Después de la primera búsqueda de datos, busque la instantánea correspondiente a través de scroll_id en la etapa de Consulta, luego use lastPageNo, realPageNo para agregar condiciones de consulta a la declaración de consulta original (pageNo = realPageNo + 1) y busque datos en la instantánea.

3. Compartir resultados

Después de que se lanzó el plan de transformación técnica, se observó intensamente el tráfico del Festival del Medio Otoño y se realizaron decenas de millones de veces de filtrado de productos diariamente, en promedio, se filtraron de 3 a 4 productos por solicitud.

Figura 4 Efectos antes y después de activar el filtrado secundario

Figura 5 Tráfico de la plataforma Jinli durante el Festival del Medio Otoño

Figura 6 Número de filtros de productos durante el Festival del Medio Otoño

Figura 7 Rendimiento de la interfaz después del filtrado de búsqueda de productos

4. Pensar y comprender

En la evolución iterativa de los productos, creemos firmemente que la tecnología puede aportar posibilidades ilimitadas a nuestro negocio. Puede ayudarnos a innovar, optimizar procesos y mejorar la eficiencia. Al mismo tiempo, también entendemos que la tecnología no es una panacea. Pero es este profundo asombro por la tecnología lo que nos mantiene humildes y de mente abierta, permitiéndonos encontrar siempre nuevos avances y superarnos a nosotros mismos.

¡Una pequeña habilidad también puede aportar un gran valor al negocio! ! !

Autor: JD Retail Mao Chenfei

Fuente: Comunidad de desarrolladores de JD Cloud Indique la fuente al reimprimir

Mejora de la experiencia: un "pequeño truco" para resolver por completo el problema de que los productos Jinli sean visibles pero no estén a la venta | Equipo técnico de JD Cloud