算法下单 策略 总结

于 2025-04-11 00:03:33 发布
阅读量1k 收藏 26
点赞数 22
文章标签： 算法 数据库 linux
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/zhangyunchou2015/article/details/147119056
版权

我们来详细探讨一下常见的算法下单（Algorithmic Trading Orders）策略。

什么是算法下单？

算法下单是指利用计算机程序，根据预设的指令、规则和参数（如时间、价格、成交量等），自动决定订单的提交时机、价格和数量，并将大额订单拆分成多个小额订单，在一段时间内逐步执行，以期达到特定目标的下单方式。

主要目标：

  1. 降低市场冲击 (Minimize Market Impact)： 大单直接进入市场会显著影响价格，对自身不利。算法单通过拆分订单、控制下单节奏来减少对市场价格的瞬间压力。
  2. 寻求更优价格 (Price Improvement)： 尝试在特定基准（如 VWAP）附近或更优的价格成交。
  3. 提高执行效率 (Increase Efficiency)： 自动化执行，减少人工操作的延迟和错误。
  4. 隐藏交易意图 (Hide Intentions)： 避免暴露大额订单的真实规模，防止被市场上的其他参与者（特别是高频交易者）“狙击”。
  5. 特定基准跟踪 (Benchmark Tracking)： 使得成交均价尽量贴近某个市场基准，如收盘价、VWAP 等。

常见的算法下单类型：

以下是一些最常见的算法下单策略，以及它们的详细说明、Python 逻辑示例和使用场景对比。

1. TWAP (Time-Weighted Average Price - 时间加权平均价格)

  • 目标： 在指定的时间段内，将订单均匀拆分执行，使得最终成交均价尽量接近该时间段内的市场时间加权平均价格。
  • 工作原理：
    • 确定总订单量 Q 和总执行时间 T。
    • 将时间 T 分割成 N 个相等的小时间段 t = T / N。
    • 在每个小时间段 t 内，平均下单 q = Q / N 的数量。
    • 通常以市价单 (Market Order) 或在买卖盘口上略微激进的限价单 (Limit Order) 执行每个小订单 q。
  • 优点：
    • 逻辑简单，易于理解和实现。
    • 对市场短期波动不敏感，平滑了单一时点执行的风险。
    • 在没有明确市场方向预期时，是一种相对中性的策略。
  • 缺点：
    • 完全忽略了市场的实际成交量分布，可能在低流动性时段强行下单，造成较大冲击或滑点。
    • 如果价格趋势明显（单边上涨或下跌），TWAP 的成交价可能会系统性地偏离最优价格。
  • Python 逻辑示例 (概念性)：
import time
import math

def execute_twap(symbol, total_quantity, duration_seconds, interval_seconds=60):
    """
    模拟执行 TWAP 订单的逻辑 (非真实交易代码)
    symbol: 交易标的代码
    total_quantity: 总下单数量
    duration_seconds: 总执行时间（秒）
    interval_seconds: 每个小订单之间的时间间隔（秒）
    """
    print(f"--- Starting TWAP Execution for {symbol} ---")
    print(f"Total Quantity: {total_quantity}, Duration: {duration_seconds}s, Interval: {interval_seconds}s")

    num_intervals = max(1, duration_seconds // interval_seconds)
    quantity_per_interval = math.ceil(total_quantity / num_intervals) # 向上取整，确保总量够
    executed_quantity = 0
    start_time = time.time()

    for i in range(num_intervals):
        current_time = time.time()
        if current_time >= start_time + duration_seconds:
            print("Duration reached. Stopping TWAP.")
            break # 超时则停止

        # 确定本次下单量
        remaining_quantity = total_quantity - executed_quantity
        order_quantity = min(quantity_per_interval, remaining_quantity)

        if order_quantity <= 0:
            break # 已经完成

        # --- 模拟下单 ---
        print(f"{time.strftime('%H:%M:%S')} - Placing order slice: {order_quantity} shares of {symbol}")
        # 在真实场景中，这里会调用交易API下单
        # success = place_order(symbol, order_quantity, order_type='MARKET')
        # if success:
        #    executed_quantity += order_quantity
        # else:
        #    handle_failed_order(...) # 处理失败逻辑
        # --- 模拟结束 ---
        executed_quantity += order_quantity # 假设下单成功

        # 等待下一个时间间隔
        sleep_time = interval_seconds - (time.time() - current_time) % interval_seconds
        if i < num_intervals - 1: # 不是最后一次则等待
             if sleep_time > 0:
                print(f"   Waiting for {sleep_time:.2f} seconds...")
                time.sleep(sleep_time)

    print(f"--- TWAP Execution Finished for {symbol} ---")
    print(f"Target Quantity: {total_quantity}, Actual Executed: {executed_quantity}") # 实际执行量可能因取整或提前结束略有差异

# --- 示例调用 ---
# execute_twap(symbol="STOCK_A", total_quantity=10000, duration_seconds=3600, interval_seconds=60)

2. VWAP (Volume-Weighted Average Price - 成交量加权平均价格)

  • 目标： 使得订单的最终成交均价尽量接近指定时间段内的市场成交量加权平均价格 (VWAP)。VWAP = Σ(价格 * 成交量) / Σ(成交量)。
  • 工作原理：
    • 预测或根据历史数据估计目标时间段内市场成交量的分布模式（例如，开盘和收盘时段成交量大，盘中较小）。
    • 根据预测的成交量分布比例，动态调整在不同时间段内的下单量。在预计市场成交量大的时段下更多的量，反之则下少量。
    • 执行方式通常也是拆分成小订单，根据实时市场成交量或预测量来决定当前小订单的大小。
  • 优点：
    • 下单节奏与市场流动性匹配度高，理论上能更好地减少市场冲击。
    • VWAP 是一个常见的交易基准，便于评估执行效果。
    • 相比 TWAP，更能适应市场内生的交易节奏。
  • 缺点：
    • 依赖于成交量预测的准确性，如果预测偏差大，效果可能不佳。
    • 实现比 TWAP 复杂，需要获取实时的或历史的成交量数据。
    • 同样地，在强趋势市场中，可能无法获得最优价格。
  • Python 逻辑示例 (概念性)：
import time
import math
import random # 用于模拟变化的市场成交量

def get_market_volume_forecast(current_time_segment, total_segments):
    """模拟获取当前时间段的市场成交量预测比例 (应基于历史数据)"""
    # 简化模拟：假设 U 型分布 (开盘收盘量大，中间小)
    if current_time_segment < total_segments * 0.2 or current_time_segment > total_segments * 0.8:
        return random.uniform(1.5, 2.5) # 相对较高的比例
    else:
        return random.uniform(0.5, 1.0) # 相对较低的比例

def execute_vwap(symbol, total_quantity, duration_seconds, interval_seconds=60):
    """
    模拟执行 VWAP 订单的逻辑 (非真实交易代码)
    """
    print(f"--- Starting VWAP Execution for {symbol} ---")
    print(f"Total Quantity: {total_quantity}, Duration: {duration_seconds}s, Interval: {interval_seconds}s")

    num_intervals = max(1, duration_seconds // interval_seconds)
    executed_quantity = 0
    start_time = time.time()

    # 1. 估算整个周期的总预测量因子 (简化)
    total_volume_factor_forecast = sum(get_market_volume_forecast(i, num_intervals) for i in range(num_intervals))
    if total_volume_factor_forecast == 0: total_volume_factor_forecast = 1 # 避免除零

    for i in range(num_intervals):
        current_time = time.time()
        if current_time >= start_time + duration_seconds:
            print("Duration reached. Stopping VWAP.")
            break

        # 2. 获取当前时间段的预测量因子
        current_volume_factor = get_market_volume_forecast(i, num_intervals)

        # 3. 计算本次下单量
        target_quantity_this_interval = math.ceil(total_quantity * (current_volume_factor / total_volume_factor_forecast))

        remaining_quantity = total_quantity - executed_quantity
        order_quantity = min(target_quantity_this_interval, remaining_quantity)
        order_quantity = max(0, order_quantity) # 确保非负

        if order_quantity <= 0 and remaining_quantity <= 0:
             break # 完成

        if order_quantity > 0:
            # --- 模拟下单 ---
            print(f"{time.strftime('%H:%M:%S')} - Volume Factor: {current_volume_factor:.2f}, Placing order slice: {order_quantity} shares of {symbol}")
            # real_api.place_order(...)
            # --- 模拟结束 ---
            executed_quantity += order_quantity # 假设成功

        # 等待
        sleep_time = interval_seconds - (time.time() - current_time) % interval_seconds
        if i < num_intervals - 1:
            if sleep_time > 0:
                print(f"   Waiting for {sleep_time:.2f} seconds...")
                time.sleep(sleep_time)

    print(f"--- VWAP Execution Finished for {symbol} ---")
    print(f"Target Quantity: {total_quantity}, Actual Executed: {executed_quantity}")

# --- 示例调用 ---
# execute_vwap(symbol="STOCK_B", total_quantity=50000, duration_seconds=7200, interval_seconds=120)

3. POV (Percentage of Volume) / Participation Rate - 成交量百分比参与

  • 目标： 使自己的订单成交量维持在市场总成交量的一个预设百分比（例如 10%）。
  • 工作原理：
    • 设定一个目标参与率 P (e.g., 0.1 for 10%)。
    • 实时监控市场的成交量 V_market。
    • 根据目标参与率计算自己的目标成交量 Q_target = V_market * P。
    • 动态调整下单速率和订单类型（如被动挂单或主动吃单），使得自己的累计成交量 Q_executed 尽量跟上 Q_target，直到总订单量完成。
    • 通常会设定一个最高下单速度限制，避免在成交量突然放大时过于激进。
  • 优点：
    • 下单行为与市场流动性高度同步，市场冲击相对较小。
    • 策略具有适应性，市场活跃时多交易，市场平淡时少交易。
    • 执行节奏更“自然”。
  • 缺点：
    • 总执行时间不确定，完全取决于市场成交量，如果市场持续低迷，订单可能无法在预期时间内完成。
    • 需要高质量的实时行情数据（特别是逐笔成交数据）。
    • 实现逻辑比 TWAP/VWAP 更复杂，需要实时计算和调整。
  • Python 逻辑示例 (概念性)：
import time
import math
import random

def get_recent_market_volume(symbol, lookback_seconds=10):
    """模拟获取最近一段时间的市场成交量"""
    # 真实场景需要连接行情 API
    # 简化模拟：返回一个随机值
    return random.randint(50, 500) * lookback_seconds / 10

def execute_pov(symbol, total_quantity, target_pov_rate=0.10, check_interval_seconds=10):
    """
    模拟执行 POV 订单的逻辑 (非真实交易代码)
    target_pov_rate: 目标参与率, e.g., 0.1 for 10%
    check_interval_seconds: 检查和调整订单的频率
    """
    print(f"--- Starting POV Execution for {symbol} ---")
    print(f"Total Quantity: {total_quantity}, Target POV Rate: {target_pov_rate*100:.1f}%")

    executed_quantity = 0
    start_time = time.time()

    while executed_quantity < total_quantity:
        current_time = time.time()

        # 1. 获取最近市场成交量
        market_volume = get_recent_market_volume(symbol, check_interval_seconds)

        # 2. 计算在此期间目标下单量
        target_quantity_this_interval = math.floor(market_volume * target_pov_rate)

        # 3. 计算需要补下的单量
        required_quantity = min(target_quantity_this_interval, total_quantity - executed_quantity)
        required_quantity = max(0, required_quantity) # 确保非负

        if required_quantity > 0:
             # --- 模拟下单 ---
             # 通常 POV 会更智能，比如先尝试被动挂单，如果跟不上进度再主动吃单
             print(f"{time.strftime('%H:%M:%S')} - Market Vol: {market_volume}, Target Slice: {required_quantity} shares of {symbol}")
             # real_api.place_smart_order(symbol, required_quantity, strategy='POV_SLICE')
             # --- 模拟结束 ---
             executed_quantity += required_quantity # 假设成功

        else:
            print(f"{time.strftime('%H:%M:%S')} - Market Vol: {market_volume}, No order needed for now.")

        # 等待下一个检查周期
        sleep_time = check_interval_seconds - (time.time() - current_time) % check_interval_seconds
        if sleep_time > 0:
            # print(f"   Waiting for {sleep_time:.2f} seconds...")
            time.sleep(sleep_time)

        # 添加一个超时或最大持续时间限制是必要的 (此处省略)
        # if time.time() - start_time > MAX_POV_DURATION:
        #     print("POV execution timed out.")
        #     break

    print(f"--- POV Execution Finished for {symbol} ---")
    print(f"Target Quantity: {total_quantity}, Actual Executed: {executed_quantity}")

# --- 示例调用 ---
# execute_pov(symbol="STOCK_C", total_quantity=20000, target_pov_rate=0.05, check_interval_seconds=5)

4. Iceberg (冰山订单) / Hidden Orders (隐藏订单)

  • 目标： 执行大额订单，但只在公开的买卖盘口（Order Book）上显示一小部分数量，隐藏真实的总订单规模。
  • 工作原理：
    • 设定总订单量 Q_total 和可见数量 Q_visible (也叫 “display size” 或 “peak”)。
    • 提交一个限价单，总数量为 Q_total，但指定可见数量为 Q_visible。
    • 当可见部分 Q_visible 被完全成交后，交易系统会自动重新补充 Q_visible 数量到盘口上，直到 Q_total 全部成交或订单被取消。
    • 补充的数量可以固定，也可以是随机的，以进一步迷惑市场观察者。
  • 优点：
    • 有效隐藏大单意图，减少被“狙击”的风险。
    • 降低大单挂出对市场价格的直接压迫感。
  • 缺点：
    • 执行速度可能较慢，因为只有在对手方主动吃掉可见部分后，后续隐藏部分才能成交。
    • 如果市场价格穿越了你的限价，订单可能无法完全成交。
    • 交易所通常对冰山订单收取更高的手续费或有特定限制。
    • 并非所有交易所都支持标准化的冰山订单类型；有时需要通过算法模拟（不断提交小限价单）。
  • Python 逻辑示例 (概念性 - 模拟交易所不支持冰山单的情况)：
import time
import math

# 假设有一个简化的订单簿和成交回报机制 (需要自行实现或对接)
# order_book = {'STOCK_D': {'bids': {price: size}, 'asks': {price: size}}}
# execution_reports = [] # 存储成交回报
# active_orders = {} # 存储自己下的活动订单 ID

def check_order_status(order_id):
    # 模拟检查订单状态，返回剩余未成交数量
    # if order_id in active_orders and active_orders[order_id]['status'] == 'FILLED':
    #    return 0
    # elif order_id in active_orders:
    #    return active_orders[order_id]['remaining_qty']
    # else: return 0 # Or handle error
    return random.choice([0, 50, 100]) # 模拟随机剩余

def place_limit_order(symbol, quantity, price, side):
    # 模拟下单，返回订单 ID
    order_id = f"order_{random.randint(1000,9999)}"
    print(f"   Placing limit {side} order: {quantity}@{price} for {symbol}. OrderID: {order_id}")
    # active_orders[order_id] = {'symbol': symbol, 'qty': quantity, 'price': price, 'side': side, 'remaining_qty': quantity, 'status': 'ACTIVE'}
    return order_id


def execute_iceberg_simulation(symbol, total_quantity, price, side, visible_quantity):
    """
    模拟执行冰山订单逻辑 (如果交易所原生不支持)
    side: 'BUY' or 'SELL'
    visible_quantity: 每次在盘口显示的数量
    """
    print(f"--- Starting Iceberg Simulation for {symbol} ---")
    print(f"Total Qty: {total_quantity}, Price: {price}, Side: {side}, Visible Qty: {visible_quantity}")

    executed_quantity = 0
    active_order_id = None

    while executed_quantity < total_quantity:
        # 检查当前是否有活动订单以及其状态
        remaining_on_market = 0
        if active_order_id:
            remaining_on_market = check_order_status(active_order_id)
            if remaining_on_market == 0:
                print(f"   Order {active_order_id} fully filled.")
                # executed_quantity += quantity_of_last_order # 需要从成交回报获取实际成交量
                active_order_id = None # 重置，准备挂新单
            # else: # 订单还在，部分成交或未成交，暂时不操作
            #    print(f"   Order {active_order_id} still active with {remaining_on_market} remaining.")
            #    pass

        # 如果没有活动订单 (刚开始或上一笔已成交)，则挂出新的一笔可见数量
        if not active_order_id:
            qty_to_place = min(visible_quantity, total_quantity - executed_quantity)
            if qty_to_place <= 0:
                break # 全部完成

            # --- 模拟下单 ---
            active_order_id = place_limit_order(symbol, qty_to_place, price, side)
            # 假设下单后，实际已执行量需要根据成交回报更新
            # 这里简化，假设挂单即代表这部分量进入执行过程
            executed_quantity += qty_to_place # !! 重要：真实逻辑要复杂得多，依赖成交回报 !!
            print(f"   Total quantity in process or executed: {executed_quantity}/{total_quantity}")


        # 等待一段时间再检查，避免过于频繁查询/下单
        time.sleep(5) # 检查间隔

        # !! 真实场景需要处理价格变动、撤单、改单逻辑 !!
        # if market_price_moves_away(price, side):
        #    cancel_order(active_order_id)
        #    re_evaluate_price_and_re_place(...)

    print(f"--- Iceberg Simulation Finished for {symbol} ---")
    print(f"Target Quantity: {total_quantity}, Quantity Processed/Executed (Simulated): {executed_quantity}")


# --- 示例调用 ---
# execute_iceberg_simulation(symbol="STOCK_D", total_quantity=100000, price=50.05, side='BUY', visible_quantity=500)

5. 其他常见算法类型

  • Sniper / Liquidity Seeking (狙击 / 流动性寻找): 积极寻找隐藏在各层级价格或不同交易场所的流动性。通常使用激进的订单类型（市价单、IOC 限价单），快速捕捉可用的对手方订单。目标是尽快成交，可能牺牲一些价格。
  • Implementation Shortfall (IS - 执行缺口): 目标是最小化从决定交易（通常有一个基准价格，如到达时的买一/卖一价）到最终完全成交的成本（包括显性成本如佣金和隐性成本如市场冲击、价格漂移）。策略会动态平衡市场冲击和价格风险，可能在价格有利时更激进，在价格不利时更保守。逻辑非常复杂，通常用于机构交易。
  • Close Price (收盘价): 目标是让成交均价尽量接近当日的收盘价。通常在临近收盘时段执行，使用类似 VWAP 或 POV 的逻辑，但时间窗口和成交量预测集中在收盘集合竞价或最后一段时间。

对比与使用场景

算法类型主要目标核心机制优点缺点典型使用场景
TWAP 时间加权接近时段均价，平滑时间风险按时间均匀拆分订单简单，中性，降低择时风险忽略成交量，趋势市可能差，冲击可能不均匀无明确方向预期；希望在一段时间内平均成本；简单基准测试
VWAP 成交量加权接近时段 VWAP，减少成交量冲击按预期/实际成交量比例拆分订单适应市场节奏，冲击较小，常用基准依赖量预测，实现稍复杂，趋势市可能差希望成交价贴近市场主流成本；交易量分布有规律时；流动性管理
POV 成交量百分比按市场节奏参与，控制参与度维持自身成交量占市场成交量的固定比例适应性强，冲击小，行为自然执行时间不确定，依赖实时数据，实现复杂对执行时间要求不高；希望“随波逐流”；低调参与市场；流动性提供策略
Iceberg 冰山隐藏大额订单意图只显示部分订单量，成交后自动补充隐藏规模，减少价格压迫感执行慢，可能无法完全成交，可能产生额外费用大额被动订单；希望在特定价格成交但不希望吓跑对手方；流动性较好处
Sniper 狙击快速成交，捕捉流动性积极寻找并以市价或激进限价吃单速度快，成交确定性高可能支付较高冲击成本（滑点大）紧急订单；需要快速建仓/平仓；套利策略执行端
IS 执行缺口最小化从决策到成交的总成本动态平衡冲击成本和价格风险，模型驱动目标明确（最小化滑点），机构常用非常复杂，依赖模型和参数，计算量大机构投资者；绩效考核基准为 IS；风险厌恶型执行
Close Price 收盘价接近收盘价临近收盘时，按量或时间比例下单满足以收盘价为基准的需求集中在收盘时段，风险和冲击较大指数基金调仓；需要以收盘价进行结算或评估的交易

重要提示:

  1. Python 示例是逻辑模拟: 上述 Python 代码是为了展示算法的核心逻辑，它们 不能 直接用于实盘交易。真实的算法交易需要：
    • 交易所/券商 API 对接: 用于下单、撤单、查询订单状态、获取市场行情数据（深度、逐笔成交等）。
    • 强大的基础设施: 低延迟网络、稳定的服务器。
    • 完善的错误处理: 网络中断、API 错误、拒单等情况的处理。
    • 严格的风险控制: 头寸限制、最大下单量限制、价格限制、止损、熔断机制等。
    • 回测与优化: 在历史数据上测试算法表现，并调整参数。
  2. 参数调优: 每种算法都有很多参数（如 TWAP 的间隔、VWAP 的量预测模型、POV 的参与率、Iceberg 的可见量等），需要根据具体市场、标的特性和交易目标进行仔细选择和优化。
  3. 组合使用: 实际交易中，可能会组合使用多种算法思想，或者根据市场状态动态切换策略。例如，一个 IS 策略内部可能在某些时候使用类似 POV 的逻辑，在另一些时候使用类似 Sniper 的逻辑。
  4. 合规性: 使用算法交易需要遵守相关国家和地区的法律法规以及交易所的规则。

希望这个详细的解释、示例和对比对您理解算法下单有所帮助！

hiquant
关注
10、IB和TWS API中一些常见的关于订单的算法
云金杞
12-05 683
IB算法 自适应算法 Adaptive Algo将IB的Smartrouting功能与用户定义的优先级设置相结合，以便在执行时进一步的降低成本。使用自适应算法可以比常规的限价单或市价单平均获得更好的执行价格。 参数 描述 值 适应性优先级 "Priority"选择器决定了扫描获得更好的执行价格所需的时间。"Urgent"设置仅进行短暂扫描，而"Patient"扫描工作速度较慢，并且更有可能为您的订单实现更好的整体成交。 Urgent>Normal >Patient baseO
Nginx高性能负载均衡：算法与策略详解
最新发布
墨夶的博客
12-12 1166
负载均衡是一种网络技术，用于将网络流量分配到多个服务器上，以提高响应速度、增加吞吐量并确保服务的可靠性和可用性。负载均衡器可以是硬件设备，也可以是软件程序。Nginx作为一种成熟的开源软件，具备强大的负载均衡能力。Nginx作为一个高性能的反向代理服务器，广泛应用于负载均衡场景。通过合理选择负载均衡算法和配置策略，可以显著提升系统的性能、可用性和稳定性。本文详细介绍了Nginx的负载均衡算法、配置方法以及优化建议，希望能帮助读者更好地理解和应用这一强大工具。
量化交易基础 - 005 - 订单执行算法
卢之
02-21 543
现在量化交易的流程和以前人为执行交易的年代并没有什么显著不同。一些交易者喜欢主动地参与执行自己的订单，而另一些则把执行订单的工作外包给经纪商去做。一些公司会把执行订单外包给提供订单执行服务的第三方公司，第三方公司会站在交易者的立场上与经纪商交涉。现在，还有些公司继续雇用人力进行人工交易，但大部分量化交易公司通过算法来执行订单。正如上文所提及的，有些公司具有自己研发的订单执行算法，另一些公司则使用经纪商或其他服务供应商所提供的算法。订单执行算法的主要目的是，以尽可能低的价格，尽可能完整地完成想要交易的订单。
订单×××的算法研究与实现
weixin_34162695的博客
02-24 207
在教学实验中，为了演示一个企业在一定时期内某种产品的订单走势，需要模拟生成一定时期内的订单。教学老师生成一系列的订单，需要选择产品、客户、订单的开始日期和结束日期，再选择一种算法。系统根据算法的预先配置，生成一系列的订单。 综合考虑以上的需求，产生订单的过程是由开始和结束日期确定产生的订单的个数，在数学的坐标中表现为x轴上的整数点，对于每个x点产生相应的y值，...
PHP的订单生成算法
liwenbo_csu的博客
07-04 4591
PHP的订单号生成算法算是语言本身的硬伤吧,相信很少的大型互联网公司会用PHP去生成订单号了,但是如果你身处一个没有各方资源的情况下还是仔细想想怎么做吧， PHP相比JAVA而言是以进程的方式运行的,进程结束资源回收,所有不会跟java一样会保存static等全局的东西(不考虑分布式),所以如果要实现一个递增的订单号必须要依赖第三方的东西比如memcache,redis,mysql等然后每次生成...
互联网大厂高频面试题基本总结回顾（含笔试高频算法整理）
热门推荐
张彦峰的博客
04-03 175万+
1.自我介绍+项目介绍+项目细节/难点提问-------这个主要看个人的经历了，每个人都不一样 2.基础知识点考核---------还是可以去增强自己的，也是这次的主要的一些总结思路 3.算法题-----------一般都是LeetCode高频题，这个得在找工作之前的好好的练习(d对常见的高频题进行总结分析，见对应的链接提示)
深入解析工厂模式与策略模式的结合：从外卖平台折扣谈起
张彦峰的博客
06-24 5万+
其实在很多的开发设计中，将工厂模式和策略模式的综合使用的案例是很多的，而且解决的实际问题也一样很多，本次对基本的简单工厂模式和策略模式做简单介绍，重点放在两者结合后的具体应用上做分析和讲解。
接口性能优化宝典：解决性能瓶颈的策略与实践
张彦峰的博客
12-01 172万+
本文深入探讨了提升接口性能的多种策略，涵盖了数据库优化、远程调用、异步处理、事务优化、缓存机制、分库分表等方面的技术。通过直面常见性能瓶颈，本文详细讲解了如何优化 SQL 执行效率、避免重复调用、减少事务复杂性、提高并发度，并提供了实际应用的最佳实践和技术方案。此外，文章还结合具体的案例，阐述了如何通过合理选择和设计优化方案，解决常见的性能问题，帮助开发者构建高效、可扩展的系统架构。
订单问题
qq_26496077的博客
12-04 514
Description Rahul and Ankit are the only two waiters in Royal Restaurant. Today, the restaurant received N orders. The amount of tips may differ when handled by different waiters, if Rahul takes the i...
算法-订单问题Java实现
qianmojl的博客
04-01 370
动态规划来实现： 首先初始化第一行， a. 只要能没有达到最大数X，就由A来做 b. 否则查找之前的A做的最小收益的任务，取当前收益与最小收益的最大值 接着更新第二行 a. 凡是A未做的，B一定会做（不然就是题目错了，X+Y一定>=N）。 b. 若A已做，比较A[i]和B[i] （1）若A[i]>B[i]，说明A来做更好 （2）否则，理论上B来做更好，事实上要分情况： a. 若B当前已做的数目小于Y（最大数），则B替换A来做 b. 若B当前已做的数目=Y，计算当前变化量B[i]-A[i]，查.
订单生成算法-雪花
蜗牛水里爬
03-09 5058
很出名的就不在啰嗦了。够实用才行据说是1秒生成上万级的ID。 自己测试烂机器 1秒生成4千多订单吧。 具体是看哪位哥们的忘了，自己改了改。存留备用。 代码如下： public class Snowflake { private final static long TWEPOCH = 1288834974657L; // 机器标识位数 private fin...
【笔记】从架构到算法，详解美团外卖订单分配内部机制
数据产品笔记
10-30 2万+
美团旗下40万骑手，峰值配送1600万单，提高配送效率意义重大，因此美团推出了用于即时配送的「超级大脑」——O2O 即时配送智能调度系统。 系统需要解决两个问题：订单分配问题&骑手路径优化问题。 同时在突发情况下，还需做到 延迟配送&自动改派 。 为了更好地训练模型，建立了一套仿真系统。 新策略能够降低 19% 的运力消耗，能在满足用户体验的情况下尽可能降低成本。
算法：电商订单问题
jerryzhou的博客
08-09 2779
描述： 有一批电商订单用数组表示如下,i，j为商品序号,k为商品种类对应的数量，n为商品类别总数。order_list=[[i,j,k]]。现设计一个算法，计算总订单量。 输入： order_list=[[0,2,5],[3,4,6],[2,4,7]];n=6 输出： list=[5,5,12,13,13,0,0];解释：0号商品5件，1号商品5件，2号商品12件…… 直接思路： 双层遍历，外层遍...
[算法]订单问题
年糕的博客
11-21 1294
订单问题 问题地址 问题描述 Description Rahul and Ankit are the only two waiters in Royal Restaurant. Today, the restaurant received N orders. The amount of tips may differ when handled by different waiters, if Ra...
城际网约车订单分配问题及其求解算法
zhangkkit的博客
05-03 7728
城际网约车订单分配问题及其求解算法问题的定义数学建模用于城际网约出行的智能订单分配算法智能订单分配算法 问题的定义   城际网约车订单分配问题是订单分配问题的一种，它主要是为了解决特定城市之间的个性化出行难题。在城际网约车服务中，订单分配问题是指在满足一定的约束条件和特定城市之间的客户出行需求的情况下，对从某个城市出发到达目标城市的一系列客户订单安排合理的接送路线，从而减少车辆的空载率，缩短客户的...
从架构到算法，详解美团外卖订单分配内部机制
机器之心
10-28 1万+
美团点评日前完成最新一轮融资，估值达到300亿美元。此轮融资后将会在人工智能、无人配送等前沿技术研发上加大投入。但我们并不是为技术而技术，事实上，人工智能技术已经在支撑着我们众多业务场景。以日订单量刚刚突破1600万的外卖业务为例，智能调度系统就是整个平台的“超级大脑”，发挥了至关重要的作用。我们将通过一系列的文章来为大家揭开这背后的技术秘密。今天是系列的第一篇，讲解外卖调度中关键难点之一——订单
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值