本申请涉及计算机
技术领域：
，尤其涉及一种购买食材的方法、装置及系统。
背景技术：
目前，用户可通过在线方式购买食材。具体的，网上提供多个食材卖家，不同的食材卖家库存的食材种类及价格等可能不同。例如用户通过手机操作，用户先挑选相应的食材卖家，在用户选定后，手机显示该食材卖家的库存的食材种类和价格等，用户可从中选择自己需要的食材，用户选择完毕后，手机生成食材清单，并将食材清单发送给该食材卖家，食材卖家接收食材清单后可为用户进行配送。其中，用户在选定相应的卖家后才能查看该卖家所提供的食材的种类和数量等，而有时用户选择的卖家可能不提供用户所需的食材，或者提供的数量不够，则用户还需退出后重新选择卖家，另外，用户进入卖家店铺后，还需逐一查看卖家提供的各类食材，以从中选择自己所需的食材。可见，目前的购买食材的方式较为复杂，需要较多的操作步骤。技术实现要素：本申请实施例提供了一种购买食材的方法、装置及系统，用于简化购买食材的过程。第一方面，提供一种购买食材的方法，包括：生成食材清单，其中，所述食材清单包括至少一种食材的名称和配送地址；将所述食材清单发送给至少一个卖家客户端；从所述至少一个卖家客户端中的第一卖家客户端接收针对所述食材清单的反馈信息，其中，所述反馈信息表示所述第一卖家客户端对应的卖家已确认配送所述食材清单上的所述至少一种食材。本申请实施例中，将食材清单直接发送给一个或者多个卖家客户端，由其中的一个卖家客户端处理食材清单，也就是说，需购买食材用户只需要确认食材清单即可，后续由卖家客户端对应的卖家来确认能否为用户配送，不需要用户自己挑选卖家，也不需要用户在卖家提供的多种食材中进行一一挑选，简化了购买食材的操作步骤，且对于需购买食材的用户所使用的设备来说需要响应的次数减少，进而降低了设备的功耗。可选的，生成食材清单，包括：接收用户输入的菜谱信息；生成所述食材清单，所述食材清单包括的所述至少一种食材用于制作所述菜谱信息对应的菜品。直接根据用户输入的菜谱信息生成用于制作该菜的食材清单，也就是，本申请实施例中，用户不需要针对需要购买的食材名称进行一一的输入，可以简化用户的操作，节省了用户的时间。同时，用户输入今天想做的菜的名称，就能生成对应的食材清单，方便用户的使用。可选的，所述食材清单还包括所述至少一种食材的数量，在生成食材清单之前，还包括：接收用户输入的第一信息，其中，所述第一信息用于指示所述至少一种食材的数量。根据用户输入的第一信息来生成至少一种食材的数量，本申请实施例中的食材清单包括了食材的数量，方便卖家配送食材。可选的，在接收针对所述食材清单的反馈信息之后，还包括：接收用户输入的第二信息，其中，所述第二信息包括对所述至少一种食材的评价；根据所述第二信息生成对所述卖家的评价信息；将所述评价信息发送给所述第一卖家客户端。根据用户输入的第二信息生成对卖家的评价信息，并且第一卖家客户端可以接收相应的评价信息。也就是，用户可以对卖家的服务或者食材质量等进行反馈，方便卖家查看用户的反馈，以便于卖家可以根据用户的反馈完善自己的服务或者提高食材质量等。第二方面，提供一种购买食材的方法，包括：买家客户端生成食材清单，其中，所述食材清单包括至少一种食材的名称和配送地址；所述买家客户端将所述食材清单发送给至少一个卖家客户端；所述至少一个卖家客户端根据所述食材清单，向服务器发送抢单信息；所述服务器向所述至少一个卖家客户端中的第一卖家客户端发送确认抢单信息，所述确认抢单信息用于指示所述第一卖家客户端抢单成功，所述第一卖家客户端为发送所述服务器接收的第一个抢单信息的卖家客户端；所述第一卖家客户端向所述买家客户端发送反馈信息，所述反馈信息表示所述第一卖家客户端对应的卖家已确认配送所述食材清单上的所述至少一种食材。买家客户端将食材清单直接发送给一个或者多个卖家客户端，服务器根据接收到卖家客户端的抢单信息的顺序确定出一个为用户配送的卖家客户端，由该卖家客户端处理食材清单，也就是说，本申请实施例中，用户只需要确认食材清单即可，不需要用户挑选卖家，也不需要用户在卖家提供的多种食材中进行挑选，简化了用户购买食材的操作步骤，并且服务器按照抢单顺序来确定配送的卖家客户端，对于众多的卖家客户端而言，这种方式更加公平合理，也能让用户的食材清单尽快的得以配送，提升用户体验。可选的，买家客户端生成食材清单，包括：所述买家客户端接收用户输入的菜谱信息；所述买家客户端生成所述食材清单，所述食材清单包括的所述至少一种食材用于制作所述菜谱信息对应的菜品。可选的，所述食材清单还包括所述至少一种食材的数量，在买家客户端生成食材清单之前，还包括：所述买家客户端接收用户输入的第一信息，其中，所述第一信息用于指示所述至少一种食材的数量。可选的，在所述第一卖家客户端向所述买家客户端发送反馈信息之后，还包括：所述买家客户端接收用户输入的第二信息，其中，所述第二信息包括对所述至少一种食材的评价；所述买家客户端根据所述第二信息生成对所述卖家的评价信息；所述买家客户端将所述评价信息发送给所述第一卖家客户端。可选的，所述方法还包括：所述至少一个卖家客户端中的每个卖家客户端分析设定的第一时间段内的销售清单，其中，所述销售清单包括在所述第一时间段内所述每个卖家客户端抢单成功的所有食材清单；所述每个卖家客户端根据所述销售清单包括的食材的名称和数量，生成第二时间段内的参考销售清单，所述第二时间段的终止时间晚于所述第一时间段的终止时间，所述参考销售清单包括所述每个卖家客户端在所述第二时间段内预计销售的食材的名称和数量。通过每个卖家客户端分析第一段时间内的销售清单，根据销售清单生成第二段时间内的参考销售清单，参考销售清单为卖家下一期进货或销售等提供了参考销售清单，本申请实施例方便卖家确定第二时间段的购进食材的种类以及数量，避免卖家购买太多食材而销售不完导致浪费或者因某种食材进货太少而造成缺货等情况。第三方面，提供一种购买食材的装置，包括：处理模块，用于生成食材清单，其中，所述食材清单包括至少一种食材的名称和配送地址；收发模块，用于将所述食材清单发送给至少一个卖家客户端，并从所述至少一个卖家客户端中的第一卖家客户端接收针对所述食材清单的反馈信息，其中，所述反馈信息表示所述第一卖家客户端对应的卖家已确认配送所述食材清单上的所述至少一种食材。可选的，所述处理模块，具体用于：接收用户输入的菜谱信息；生成所述食材清单，所述食材清单包括的所述至少一种食材用于制作所述菜谱信息对应的菜品。可选的，所述食材清单还包括所述至少一种食材的数量，所述处理模块，还用于：在生成食材清单之前，接收用户输入的第一信息，其中，所述第一信息用于指示所述至少一种食材的数量。可选的，所述处理模块，还用于接收用户输入的第二信息，根据所述第二信息生成对所述卖家的评价信息，其中，所述第二信息包括对所述至少一种食材的评价；所述收发模块，还用于将所述评价信息发送给所述第一卖家客户端。第四方面，提供一种购买食材的系统，包括：买家客户端，用于生成食材清单，将所述食材清单发送给至少一个卖家客户端，以及，从所述至少一个卖家客户端中的第一卖家客户端接收反馈信息，其中，所述食材清单包括至少一种食材的名称和配送地址，所述反馈信息表示所述第一卖家客户端对应的卖家已确认配送所述食材清单上的所述至少一种食材；所述至少一个卖家客户端，用于从所述买家客户端接收所述食材清单，并根据所述食材清单，向服务器发送抢单信息；所述服务器，用于向所述至少一个卖家客户端中的第一卖家客户端发送确认抢单信息，所述确认抢单信息用于指示所述第一卖家客户端抢单成功，所述第一卖家客户端为发送所述服务器接收的第一个抢单信息的卖家客户端；所述第一卖家客户端，用于从所述服务器接收所述确认抢单信息，并向所述买家客户端发送所述反馈信息。可选的，所述买家客户端具体用于：接收用户输入的菜谱信息；生成所述食材清单，所述食材清单包括的所述至少一种食材用于制作所述菜谱信息对应的菜品。可选的，所述食材清单还包括所述至少一种食材的数量，所述买家客户端还用于：在生成食材清单之前，接收用户输入的第一信息，其中，所述第一信息用于指示所述至少一种食材的数量。可选的，所述买家客户端还用于：在从所述第一卖家客户度接收针对所述食材清单的反馈信息之后，接收用户输入的第二信息，其中，所述第二信息包括对所述至少一种食材的评价；根据所述第二信息生成对所述卖家的评价信息；将所述评价信息发送给所述第一卖家客户端。可选的，所述至少一个卖家客户端中的每个卖家客户端，还用于：分析设定的第一时间段内的销售清单，其中，所述销售清单包括在所述第一时间段内所述每个卖家客户端抢单成功的所有食材清单；根据所述销售清单包括的食材的名称和数量，生成第二时间段内的参考销售清单，所述第二时间段的终止时间晚于所述第一时间段的终止时间，所述参考销售清单包括所述每个卖家客户端在所述第二时间段内预计销售的食材的名称和数量。第五方面，提供一种购买食材的装置，包括：至少一个处理器，以及与所述至少一个处理器通信连接的存储器；其中，所述存储器存储有可被所述至少一个处理器执行的指令，所述至少一个处理器通过执行所述存储器存储的指令实现如第一方面及任一可选的实施方式所述的方法。第六方面，提供一种计算机可读存储介质，所述计算机可读存储介质存储有计算机指令，当所述计算机指令在计算机上运行时，使得计算机执行如第一方面及任一可选的实施方式所述的方法或第二方面及任一可选的实施方式所述的方法。本申请实施例中提供的一个或多个技术方案，至少具有如下技术效果或优点：本申请实施例中，将食材清单直接发送给一个或者多个卖家客户端，由其中的一个卖家客户端进行配送。也就是，用户只需要确认食材清单中的是否包括了自己想要购买的所有食材即可，后续由卖家客户端对应的卖家来确认能否为用户配送，确认配送的卖家是能为用户配送的是能够提供食材清单上的食材的卖家，不需要用户自己挑选卖家，也不需要用户在卖家提供的多种食材中进行一一挑选，简化了购买食材的操作步骤，对于用户所使用的设备来说需要响应的次数减少，进而降低了用户使用的设备的功耗。附图说明图1为本申请实施例的一种应用场景的示意图；图2为本申请实施例提供的一种购买食材的方法的流程图；图3为本申请实施例中用户输入的菜谱信息的一种示意图；图4为本申请实施例中根据图3所示菜谱信息生成的食材清单的一种示意图；图5为本申请实施例中接收用户输入的第一信息后生成的食材清单的一种示意图；图6为本申请实施例中接收用户输入的第一信息后生成的食材清单的一种示意图；图7为本申请实施例中根据图6的食材清单生成的抢单信息的一种示意图；图8为本申请实施例中根据图7的抢单信息生成的确认抢单信息的一种示意图；图9为本申请实施例中根据图6的食材清单生成的反馈信息的一种示意图；图10为本申请实施例提供的购买食材的装置的一种结构示意图；图11为本申请实施例提供的购买食材的装置的一种结构示意图。具体实施方式为了更好地理解本申请实施例提供的技术方案，下面将结合说明书附图以及具体的实施方式进行详细的说明。本申请实施例提供了一种购买食材的方法，用于简化购买食材的操作过程。下面介绍本申请实施例的应用场景。请参见图1，为本申请实施例的一种应用场景，或者，图1也可以理解为是本申请实施例提供的一种购买食材的系统。在该应用场景下，包括买家客户端110、服务器120和至少一个卖家客户端130。图1中，以3个卖家客户端130为例，在实际应用中不限制卖家客户端130的数量。在图1所示的场景下，买家客户端110和至少一个卖家客户端130可以通过服务器120进行通信，服务器120除了可以用于进行消息的转发之外，还可以对消息做其它处理，具体将在后文的实施例中介绍。或者，图1虽然只画出了买家客户端110和至少一个卖家客户端130通过服务器120进行通信的情况，但在图1所示的场景下，买家客户端110和至少一个卖家客户端130也可以直接进行通信，不用通过服务器120进行中转。其中，本申请实施例所述的买家客户端110，可以是实体设备，例如为终端设备，例如手机(图1中是以手机为例)、个人计算机(pc)或平板电脑(pad)等，或者，买家客户端110也可以是软件模块，例如可以是安装在实体设备中的应用(app)等。同理，至少一个卖家客户端130中的卖家客户端130也可以是实体设备或软件模块。本申请实施例所述的服务器120可以是云端服务器，或者可以是普通的服务器。如上介绍了本申请实施例的应用场景，下面结合上述应用场景介绍本申请实施例提供的技术方案。请参见图2，本申请实施例提供一种购买食材的方法，在下面的介绍过程中，以该方法应用在图1所示的应用场景为例。该方法的流程如下：步骤21、买家客户端110生成食材清单，其中，食材清单包括至少一种食材的名称和配送地址；步骤22、买家客户端110将食材清单发送给至少一个卖家客户端130；步骤23、至少一个卖家客户端130根据食材清单，向服务器120发送抢单信息；步骤24、服务器120向至少一个卖家客户端130中的第一卖家客户端130发送确认抢单信息，确认抢单信息用于指示第一卖家客户端130抢单成功，第一卖家客户端130为发送服务器120接收的第一个抢单信息的卖家客户端130；步骤25、第一卖家客户端130向买家客户端110发送反馈信息，反馈信息表示第一卖家客户端130对应的卖家已确认配送食材清单上的至少一种食材。在本实施例中，买家客户端110可以是需购买的用户使用的设备，例如手机，或者是需购买的用户使用的设备中的软件模块，例如为图1所示的场景中的买家客户端110，或者，本实施例中的买家客户端110也可以通过服务器120实现，例如通过图1所示的场景中的服务器120实现。图2中，以至少一个卖家客户端130包括第一卖家客户端130和第二卖家客户端130为例，第一卖家客户端130和第二卖家客户端130可以是图1所示的场景中的任意两个卖家客户端130。先以买家客户端110是图1所示的场景中的买家客户端110为例。例如，用户打算购买食材做菜，则用户可以直接通过买家客户端110输入食材信息，食材信息例如包括用户所需的食材的名称，还可以包括食材的数量和可接受的价格范围等信息中的至少一种。买家客户端110接收用户输入的食材信息后就可以根据该食材信息生成食材清单。或者，为了更方便用户，用户也可以直接输入菜谱信息，菜谱信息例如为菜名，例如麻婆豆腐、番茄炒蛋或水煮鱼片等，或者也可以更为详细，例如为用户地域和菜名的组合，例如广式麻婆豆腐。买家客户端110接收用户输入的菜谱信息后，可以根据该菜谱信息生成相应的食材清单，该食材清单里包括的食材就用于制作该菜谱信息对应的菜品。例如，请参照图3，买家客户端110为安装在手机中的用于购买食材的app，用户打开该app，该app显示主页，app主页上包括输入框和一些可供用户点击的触摸键，例如“选择菜谱”、“选择食材”、“购买”和“我的”触摸键。其中，用户可以点击“选择菜谱”来选择app直接推荐的一些菜谱，买家客户端110再根据用户选择的菜谱生成食材清单；或者，用户也可以点击“选择食材”进入食材购买界面，直接选择相应的食材；或者，为了节省用户查找时间，用户也可以直接在app主页的输入框中输入菜谱信息。例如用户在app主页中的输入框直接输入了“番茄炒蛋”，则相当于买家客户端110接收用户输入的信息“番茄炒蛋”。其中，用户可以通过语音输入、文字输入或者手势输入等方式输入食材信息或菜谱信息，对于具体的输入方式不作限制。在本实施例中，食材清单除了包括至少一种食材的名称之外，为了方便卖家客户端130能够为买家配送，食材清单还可以包括配送地址，也就是买家客户端110对应的买家所在的地址。那么，该配送地址可以由用户直接输入，例如用户在输入食材信息或菜谱信息时一并输入配送地址，或者，该配送地址可以由买家客户端110通过定位信息获得，该配送地址也就是买家客户端110的地址，或者，该配送地址也可以存储在买家客户端110中，买家客户端110生成食材清单时可直接附上配送地址，例如买家客户端110可支持多个账号，不同的账号可对应不同的配送地址，用户输入食材信息或菜谱信息时，可在相应的账号下输入，则买家客户端110可以直接在食材清单中添加该账号对应的配送地址。关于配送地址，可由买家客户端110直接加入，因此下面主要介绍买家客户端110如何生成食材清单中的食材信息。其中，如果用户输入的是食材信息，则买家客户端110可以直接生成食材清单，而如果用户输入的是菜谱信息，则买家客户端110还需根据该菜谱信息确定食材信息后才能生成食材清单。关于买家客户端110根据菜谱信息生成食材清单的方式，包括但不限于如下几种：方式一，买家客户端110根据预先存储的菜谱信息与食材的对应关系，生成食材清单。例如，买家客户端110可以将输入菜谱信息与食材的对应关系预先存储，则买家客户端110可以将该对应关系存储在本地，例如买家客户端110为手机或手机中的app，则买家客户端110可以将该对应关系存储在手机本地，或者，买家客户端110也可以将该对应关系存储在云端，例如可以存储在图1所示的应用场景中的服务器120中。在接收用户输入的菜谱信息后，买家客户端110可以直接查询该对应关系，根据该对应关系确定该菜谱信息对应的食材，则买家客户端110可以根据确定的食材以及配送地址生成食材清单。例如，用户输入的菜谱信息是“番茄炒蛋”，买家客户端110通过查询该对应关系，确定与“番茄炒蛋”对应的食材包括“番茄、鸡蛋和盐”，则买家客户端110可以根据这三种食材以及配送地址生成食材清单。方式二，买家客户端110通过网络搜索菜谱信息对应的食材，以生成食材清单。例如，买家客户端110接收用户输入的菜谱信息，可调用相应的搜索引擎进行搜索，对于具体的搜索引擎不作限制。通过搜索，买家客户端110可以确定与该菜谱信息对应的食材，则买家客户端110可以根据确定的食材以及配送地址生成食材清单。例如，用户输入的菜谱信息是“番茄炒蛋”，买家客户端110将“番茄炒蛋”作为关键词，在搜索引擎中进行搜索，确定与“番茄炒蛋”对应的食材包括“番茄、鸡蛋和盐”，则买家客户端110可以根据这三种食材以及配送地址生成食材清单。其中，通过搜索引擎搜索，可能会得到多种结果，例如，买家客户端110可以确定一种与“番茄炒蛋”对应的食材组合包括“番茄、鸡蛋和盐”，还可以确定另一种与“番茄炒蛋”对应的食材组合包括“番茄、鸡蛋、葱和盐”，则买家客户端110可以任选其中的一种来生成食材清单，或者，也可以由用户从搜索结果中选择一种，买家客户端110根据用户选择的食材来生成食材清单。方式三，买家客户端110根据预先存储的菜谱信息与链接的对应关系，生成食材清单。例如，买家客户端110将菜谱信息与对应的食材信息以链接的形式存储。也就是说，菜谱信息以及菜谱信息对应的食材信息是链接的形式预先存储在买家客户端110的。链接可以直接存储在买家客户端110中，或者，也可以存储在云端，例如可以存储在图1所示的应用场景中的服务器120中。以链接的形式来存储食材信息，相对于方式一来说，能够节省存储空间。在接收用户输入的菜谱信息后，买家客户端110可以查询菜谱信息与链接的对应关系，获得该菜谱信息对应的链接，再通过打开该链接来获得对应的食材。例如，买家客户端110对应番茄炒蛋存储的是“https://w.com”，当买家客户端110接收到用户输入的“番茄炒蛋”之后，直接由买家客户端110在搜索引擎中打开“https://w.com”链接，获得该链接的对应的“番茄、蛋和盐”三种食材的信息，再由买家客户端110根据配送地址和这三种食材的信息生成食材清单。上述只是根据菜谱信息生成食材清单的方式的几种示例，本实施例中生成食材清单的方式并不限于上述几种。买家客户端110在确定菜谱信息对应的食材后，可以生成食材清单。例如，用户在图3所示的购买食材的app主页中的输入框中输入了“番茄炒蛋”，买家客户端110生成了图4所示的食材清单，该食材清单包括了“番茄、鸡蛋和盐”三种食材以及配送地址。在图4所示的食材清单中，只是包括了食材的名称和配送地址，在本实施例中，食材清单还可以包括食材的数量。具体的，买家客户端110可以根据用户输入的第一信息来确定食材的数量，然后买家客户端110根据第一信息以及菜谱信息生成食材清单。其中，第一信息和食材信息(或菜谱信息)可以是两条信息，用户可以同时输入第一信息和食材信息(或菜谱信息)，或者先输入第一信息后输入食材信息(或菜谱信息)，或者先输入食材信息(或菜谱信息)后输入第一信息，或者，第一信息和食材信息可以是同一条信息，例如第一信息就包括了食材信息以及食材的数量。另外，如果用户输入的食材信息，则用户可以直接确定第一信息，而如果用户输入的是菜谱信息，则用户可能并不知道该菜谱信息所涉及的食材，因此用户可能没办法直接输入第一信息。在用户输入的是菜谱信息的情况下，买家客户端110可以直接根据惯例(例如制作一道家常菜品所需的食材的数量)来确定食材的数量，无需用户输入，例如，用户输入了“番茄炒蛋”，买家客户端110直接根据惯例生成了如图5所示的食材清单，该食材清单默认番茄的数量为2个、鸡蛋数量为1个和盐的数量为1斤。或者，在买家客户端110根据菜谱信息确定食材后，可以输出提示信息，以提示用户输入对食材的需求量，则用户可以根据该提示信息在买家客户端110输入第一信息，第一信息就用于指示食材的数量。例如，第一信息和食材信息是两条不同的信息，用户输入的食材信息包括“番茄、鸡蛋和盐”，用户还输入了第一信息，第一信息指示盐的数量为0、番茄的数量为2和鸡蛋的数量为1，则买家客户端110接收用户输入的食材信息和第一信息后，生成了如图6所示的食材清单。在前文的介绍过程中，是以买家客户端110是图1所示的应用场景中的买家客户端110为例，而如果买家客户端110是图1所示的场景中的服务器120，那么服务器120在生成食材清单时，可以是图1所示的场景中的买家客户端110接收用户输入的信息，例如，接收用户输入的食材信息或菜谱信息，图1所示的场景中的买家客户端110将接收的用户输入的信息发送给服务器120，由服务器120生成食材清单，具体的生成方式可参考前文的介绍。买家客户端110生成食材清单后，可以将食材清单发送给至少一个卖家客户端130，其中，如果买家客户端110是图1所示的场景中的买家客户端110，则买家客户端110可以将食材清单发送给服务器120，由服务器120转发给至少一个卖家客户端130，或者，如果买家客户端110是图1所示的场景中的服务器120，则该服务器120可以直接将食材清单发送给至少一个卖家客户端130。当然，买家客户端110也可以根据相应的条件来限制发送食材清单的卖家客户端130的数量。例如根据距离条件来限制卖家客户端130的数量，例如，买家客户端110选择将食材清单发送给与买家客户端110之间的距离小于或等于1km的卖家客户端130，这样可以提高传输的成功率。买家客户端110将食材清单发送给至少一个卖家客户端130之后，至少一个卖家客户端130接收该食材清单，则至少一个卖家客户端130可以确定是否能够提供该食材清单对应的食材，确定能够提供该食材清单对应的食材的卖家客户端130可以根据该食材清单，向服务器120发送抢单信息，抢单信息用于表示该卖家客户端130请求提供该食材清单对应的食材，对于抢单信息的具体形式，本实施例不作限制。例如，抢单信息可以包括食材清单的所有内容，或者买家客户端110可以为生成的食材清单设置编号，抢单信息可以包括对应的食材清单的编号，总之，考虑到服务器120可能接收针对多个食材清单的抢单信息，因此一个卖家客户端130所发送的抢单信息，需要让服务器120能够确定是针对哪个食材清单的抢单信息。例如卖家客户端130为安装在手机中的app，在该卖家客户端130接收到了如图6所示的食材清单后，根据图6的食材清单生成了如图7所示的抢单信息，该抢单信息包括了食材的名称、配送地址以及抢单标识，服务器120可以根据该抢单信息包括的内容确定该抢单信息针对的是哪个食材清单，其中，图7中的app界面上还包括了卖家的当前定位地址“xx省xl楼”以及一些卖家常用的功能触摸键，功能触摸键例如“订单”和“我的”，卖家可以点击“订单”查看自己的接单情况，或者点击“我的”查看自己的商家信息。其中，向服务器120发送抢单信息的卖家客户端130，可以包括至少一个卖家客户端130中的全部卖家客户端130或者部分卖家客户端130。关于卖家客户端130生成抢单信息，包括但不限于如下两种方式：例如，由卖家客户端130根据卖家的抢单指令来生成抢单信息。以其中一个卖家客户端130为例。该卖家客户端130接收食材清单后，可以通过显示屏进行显示，以供该卖家客户端130对应的卖家查看，该卖家查看后，如认为能够提供该食材清单对应的食材，则该卖家可以向卖家客户端130发送抢单指令，该卖家客户端130接收抢单指令后可生成抢单信息，并将抢单信息发送给服务器120。或者，由卖家客户端130直接生成抢单信息。以其中一个卖家客户端130为例。该卖家客户端130预先存储了该卖家客户端130对应的卖家所能够提供的食材的名称和数量等信息，则该卖家客户端130接收食材清单后，可以根据预先存储的信息确定是否能够提供该食材清单对应的食材，如确定能够提供该食材清单对应的食材，则该卖家客户端130可生成抢单信息，并将抢单信息发送给服务器120。对于服务器120来说，针对一个食材清单，可能会接收多个卖家客户端130所发送的抢单信息，而对于买家来说，只需一个卖家为其提供食材即可，因此服务器120需要从多个卖家客户端130里选择一个卖家客户端130来为买家进行配送。较为公平的一种选择方式是，服务器120根据接收抢单信息的顺序来选择卖家客户端130。例如，服务器120接收了至少一个卖家客户端130发送的抢单信息，其中的第一个抢单信息是至少一个卖家客户端130中的第一卖家客户端130发送的，那么服务器120就选择第一卖家客户端130为买家进行配送。那么服务器120可以生成确认抢单信息，确认抢单信息就用于指示第一卖家客户端130抢单成功，服务器120将确认抢单信息发送给第一卖家客户端130。例如，服务器120接收卖家客户端130发送的如图7所示的抢单信息之后，向第一卖家客户端130发送了如图8所示的确认抢单信息，该确认抢单信息包括了食材清单的具体信息以及明确的抢单成功的标识。第一卖家客户端130接收确认抢单信息后，就可以准备食材清单中所包括的食材，并根据食材清单包括的配送地址进行配送。而向服务器120发送抢单信息的卖家客户端130可能有多个，服务器120只确认其中的第一卖家客户端130抢单成功，对于其他的卖家客户端130，服务器120也可以向这些卖家客户端130发送抢单失败的信息，接收了抢单失败的信息的卖家客户端130就可以确定抢单失败，不再处理该食材清单。或者，对于其他的卖家客户端130，服务器120也可以不发送抢单失败的信息，例如每个卖家客户端130都可以设置定时器，如果服务器120向卖家客户端130发送确认抢单信息，会在该定时器超时之前发送，则卖家客户端130会在该定时器超时之前接收确认抢单信息，那么在该定时器超时前，如果未接收服务器120发送的信息，则卖家客户端130可以确定抢单失败。另外，有可能第一卖家客户端130接收服务器120发送的确认抢单信息之后，第一卖家客户端130对应的卖家由于个人原因等又想取消配送，那么该卖家可以向第一卖家客户端130发送取消配送指令，第一卖家客户端130根据取消配送指令生成取消配送信息，并将取消配送信息发送给服务器120，那么服务器120可以重新选择卖家客户端130。例如，服务器120依旧根据之前接收抢单信息的顺序来选择卖家客户端130，第一卖家客户端130是服务器120所接收的第一个抢单信息对应的卖家客户端130，既然第一卖家客户端130取消配送，那么服务器120可以顺序选择接收的第二个抢单信息对应的卖家客户端130，服务器120再向该卖家客户端130发送确认抢单信息。通过这种方式，可以尽量保证买家的需求得到满足。因为只有服务器120知晓哪个卖家客户端130能够为买家进行配送，但对于买家来说，一般也希望知道卖家的信息。因此，第一卖家客户端130接收服务器120发送的确认抢单信息之后，可以向买家客户端110发送反馈信息，该反馈信息表示第一卖家客户端130对应的卖家已确认配送食材清单所包括的食材，以使得买家可以安心等待配送。例如，第一卖家客户端130接收服务器120发送的如图8所示的确认抢单信息，则第一卖家客户端130生成了如图9所示的反馈信息，然后发送给了买家客户端110，以告知用户，该卖家已经接单。其中，第一卖家客户端130可以将反馈信息发送给服务器120，由服务器120发送给买家客户端110，或者第一卖家客户端130也可以直接将反馈信息发送给买家客户端110。可以看到，这里的买家客户端110，指的是图1所示的场景中的买家客户端110。买家客户端110在接收针对食材清单的反馈信息之后，或者，在收到第一卖家客户端130配送的至少一种食材后，买家客户端110可以生成对至少一种食材和/或第一卖家客户端130对应的卖家的评价信息。这里的买家客户端110，是指图1所示的买家客户端110。例如，在接收针对食材清单的反馈信息之后，或者，在收到第一卖家客户端130配送的至少一种食材后，用户可以向该买家客户端110输入第二信息，第二信息可以包括对至少一种食材和/或第一卖家客户端130对应的卖家的评价，则买家客户端110可以根据第二信息生成对至少一种食材和/或第一卖家客户端130对应的卖家的评价信息。买家客户端110可以将评价信息发送给服务器120，由服务器120转发给第一卖家客户端130，或者买家客户端110也可以直接将该评价信息发送给第一卖家客户端130。或者，在接收针对食材清单的反馈信息之后，或者，在收到第一卖家客户端130配送的至少一种食材后，用户可以向图1所示的场景中的买家客户端110输入第二信息，第二信息可以包括对至少一种食材和/或第一卖家客户端130对应的卖家的评价，买家客户端110将第二信息发送给服务器120，由服务器120来生成对至少一种食材和/或第一卖家客户端130对应的卖家的评价信息，再将该评价信息发送给第一卖家客户端130。第一卖家客户端130接收评价信息后，可以通过显示屏进行显示，以供第一卖家客户端130对应的卖家查看，从而该卖家可以根据用户的评价信息完善自己的服务或者提高食材质量等。其中，评价信息可以包括买家关于食材和/或卖家的评论等，评价信息的形式可以包括文字、评分、图片或者视频中的一种或者多种，具体的不作限制。例如，评价信息包括的对其中一种食材的评价为，该食材的新鲜程度为4颗星。对于卖家客户端130来说，希望对销售情况有所统计，从而也能够更好的规划下一时期的进货或者销售安排，例如确定应购买哪些食材以及食材的数量。因此在本实施例中，卖家客户端130可以通过对已售出的货品进行分析，来得到下一时期的参考销售清单。例如，至少一个卖家客户端130中的每个卖家客户端130都可以做这种分析。那么，每个卖家客户端130可以分析设定的第一时间段内的销售清单，其中，所分析的销售清单包括在第一时间段内每个卖家客户端130抢单成功的所有食材清单，第一时间段可以是卖家客户端130自行设定的时间段，或者也可以是卖家设定的时间段，例如卖家可以根据自己的进货周期等因素来设置。每个卖家客户端130根据所分析的销售清单包括的食材的名称和数量，可以生成第二时间段内的参考销售清单，第二时间段的终止时间晚于第一时间段的终止时间，也就是说，第二时间段是下一时期，对于第二时间段的长度不作限制。参考销售清单包括每个卖家客户端130在第二时间段内预计销售的食材的名称和数量。也就是说，卖家客户端130可以根据上一时期的销售情况来预计下一时期的销售，从而为卖家进货等提供参考。例如，可将第一时间段的销售清单包括的全部的食材的信息添加到参考销售清单中，也就是说，参考销售清单包括该销售清单中的全部的食材的名称，食材的数量也与该销售清单一致，需注意的是，第一时间段的销售清单可能包括多个，可能不同的销售清单中会包括相同的食材，那么，这里所述的销售清单中的食材的数量，可以是指同一种食材在所有的销售清单中的数量的累加值。或者，也可确定第一时间段的销售清单中的需求量较大的食材的信息，将这些食材的信息添加到参考销售清单中，作为参考销售清单包括的食材的信息。需求量较大，可理解为数量较多，例如，可确定第一时间段的销售清单中包括的、数量大于预设数量的食材的信息，将这部分食材的信息添加到参考销售清单中，使得参考销售清单更有针对性。预设数量可以由卖家客户端设置，或者可以由卖家客户端对应的卖家设置。例如，至少一个卖家客户端130中的卖家客户端a设置的第一时间段的时长为一个月，其中，第一时间段具体为2018年1月。卖家客户端a确定在2018年1月内共接收了服务器120发送的两个确认抢单信息，分别对应第一食材清单和第二食材清单，那么，卖家客户端a对应的销售清单就包括第一食材清单和第二食材清单。例如第一食材清单包括的食材的名称和数量如下表1所示，第二食材清单包括的食材的名称和数量如下表2所示：表1鸡蛋3个番茄3个猪肉4斤表2豇豆2个番茄4个猪肉6斤卖家客户端a对第一食材清单和第二食材清单进行分析得到2018年1月份的销售清单，然后根据该销售清单包括的食材的名称和数量就可以得到第二时间段的参考销售清单，第二时间段例如为2018年2月。一种参考销售清单如表3所示，表3是以将该销售清单包括的全部的食材的信息添加到参考销售清单中为例：表3鸡蛋3个番茄7个猪肉4斤豇豆2个猪肉6斤也就是说，在2018年1月结束之后，卖家客户端a对应的卖家可以根据参考销售清单来购进2018年2月预计销售的货物，从而能够自动分析销售情况，为卖家进货提供参考。另外，在累积了多个时间段的多个销售清单的之后，卖家客户端130下一个的参考销售清单可以是参照紧挨着的上一个时间段的销售清单生成，或者，也可以是前几个时间段的多个销售清单的食材名称进行统计得到参考销售清单的食材名称，根据前几个时间段的多个销售清单的食材对应的数量进行加权平均之后得到参考销售清单的食材数量，进而得到该参考销售清单的详细内容。例如，卖家打算进2018年3月份的货物，可以将2018年1月份销售清单中的食材数量和2018年2月份的销售清单中的食材数量进行加权平均之后得到2018年3月份的参考销售清单中食材数量。其中，参考销售清单只是个参考值，卖家可以根据实际情况在这个参考值的基础上调整具体进货量。本申请实施例不需要用户挑选卖家，也不需要用户在卖家提供的多种食材中进行挑选，简化了购买食材的操作步骤，对于用户所使用的设备来说需要响应的次数减少，进而降低了用户使用的设备的功耗。在上述购买食材的方法的基础上，本申请实施例还提供了一种购买食材的装置，该购买食材的装置可以是如前所述的买家客户端。请参照图10，该装置包括：处理模块1001和收发模块1002。具体的，处理模块1001，用于生成食材清单，其中，食材清单包括至少一种食材的名称和配送地址；收发模块1002，用于将食材清单发送给至少一个卖家客户端130，并从至少一个卖家客户端130中的第一卖家客户端130接收针对食材清单的反馈信息，其中，反馈信息表示第一卖家客户端130对应的卖家已确认配送食材清单上的至少一种食材。可选的，处理模块1001，具体用于：接收用户输入的菜谱信息；生成食材清单，食材清单包括的至少一种食材用于制作菜谱信息对应的菜品。可选的，食材清单还包括至少一种食材的数量，处理模块1001，还用于：在生成食材清单之前，接收用户输入的第一信息，其中，第一信息用于指示至少一种食材的数量。可选的，处理模块1001，还用于接收用户输入的第二信息，根据第二信息生成对卖家的评价信息，其中，第二信息包括对至少一种食材的评价；收发模块1002，还用于将评价信息发送给第一卖家客户端130。在前文描述的一种购买食材的方法的基础上，本申请实施例提供了一种购买食材的系统，该系统可继续参照图1，该系统包括：买家客户端110，用于生成食材清单，将食材清单发送给至少一个卖家客户端130，以及，从至少一个卖家客户端130中的第一卖家客户端130接收反馈信息，其中，食材清单包括至少一种食材的名称和配送地址，反馈信息表示第一卖家客户端130对应的卖家已确认配送食材清单上的至少一种食材；至少一个卖家客户端130，用于从买家客户端110接收食材清单，并根据食材清单，向服务器120发送抢单信息；服务器120，用于向至少一个卖家客户端130中的第一卖家客户端130发送确认抢单信息，确认抢单信息用于指示第一卖家客户端130抢单成功，第一卖家客户端130为发送服务器120接收的第一个抢单信息的卖家客户端130；第一卖家客户端130，用于从服务器120接收确认抢单信息，并向买家客户端110发送反馈信息。可选的，买家客户端110具体用于：接收用户输入的菜谱信息；生成食材清单，食材清单包括的至少一种食材用于制作菜谱信息对应的菜品。可选的，买家客户端110还用于：在生成食材清单之前，接收用户输入的第一信息，其中，第一信息用于指示至少一种食材的数量。可选的，买家客户端110还用于：在从第一卖家客户度接收针对食材清单的反馈信息之后，接收用户输入的第二信息，其中，第二信息包括对至少一种食材的评价；根据第二信息生成对卖家的评价信息；将评价信息发送给第一卖家客户端130。可选的，至少一个卖家客户端130中的每个卖家客户端130，还用于：分析设定的第一时间段内的销售清单，其中，销售清单包括在第一时间段内每个卖家客户端130抢单成功的所有食材清单；根据销售清单包括的食材的名称和数量，生成第二时间段内的参考销售清单，第二时间段的终止时间晚于第一时间段的终止时间，参考销售清单包括每个卖家客户端130在第二时间段内预计销售的食材的名称和数量。其中，图1中的卖家客户端130是以3个为例，但是在实际应用中卖家客户端130的数量可以是一个到多个，本申请实施例不做限制。在前文的一种购买食材的方法的基础上，本申请实施例提供一种购买食材的装置。请参照图11，该装置包括：至少一个处理器1101，以及与至少一个处理器1101通信连接的存储器1102；其中，存储器1102存储有可被至少一个处理器1101执行的指令，至少一个处理器1101通过执行存储器1102存储的指令实现如前文图2所示的买家客户端110执行的方法。作为一种示例，图10所示的购买食材的装置中的处理模块1001可通过图11所示的购买食材的装置中的处理器1101实现。需注意的是，在图11中，以购买食材的装置包括一个处理器1101为例，在实际应用中并不限制购买食材的装置包括的处理器1101的数量。另外在本申请实施例中，如果买家客户端110和卖家客户端130为软件模块，则买家客户端110和卖家客户端130可以是不同类型的客户端，或者也可以是同一类型的客户端，例如买家客户端110和卖家客户端130为app形式的软件模块，无论对于买家还是卖家来说，都可以下载同一种app，而该app可支持不同的账号，不同的账号对应不同的权限，如果用户通过具有买家权限的账号登录该app，那么该app就视为买家客户端110，如果用户通过具有卖家权限的账号登录该客户端，那么该app就视为卖家客户端130。在前文的一种购买食材的方法的基础上，本申请实施例提供一种计算机可读存储介质，计算机可读存储介质存储有计算机指令，当计算机指令在计算机上运行时，使得计算机执行如前文图2所示的买家客户端110、服务器120和卖家客户端130中的至少一种装置购买食材的方法。本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。尽管已描述了本申请的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。当前第1页12